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POLICY-- Pascal User's Group and Pascal Newsletter 

USER*S GROUP POLICIES 

Membership - is open to anyone: particularly Pascal users, teachers, maintainers, 
implementors, distributors, or just plain fans. 
Institutional memberships, especially libraries are encouraged. 
The cost of membership is $4 per academic year ending June 30. Anyone 
joining anytime for a particular year will receive all 4 quarterly 
issues of PcUiCal Hmj^ldttojt for that year. (In other words back issues 
are sent automatically). See ALL PURPOSE COUPON on back cover. 
First time members receive a receipt for membership; renewers do not 
to save money for PUG on postage. 

Purposes - are to promote the ideas behind Pascal as well as the use of the 

programming language Pascal. Pascal is a practical language with a 
^ small , systematic , and general purpose structure which is being 
used for: 

* teaching programming concepts 

* developing reliable "production" software 

* implementing software efficiently on today's machines 

* writing portable software 

Ltt^^ QZt moKt a6gA6 yinvotve^d " ci/ige youx Pascal inlund^ tx) join ?UG iA)htthQA {act 
to {acd OK maybd through, an annoiinadrnznt X.n yonn, Zn6ta£tatlon^ 6 tocat nmhlnttoA,. 

NEWSLETTER POLICIES 

The Pa6ea£ HmJ^ltttoJi is the official but informal publication of the User's Group. 
It is produced quarterly (usually September, November, February, and 
May). A complete membership list is printed in the November issue. 
Single back issues are available for $1 each. Out of print: #s 1,2,3. 

The contribution by PUG members of ideas, queries, articles, letters, and opinions 
for the Hm^ldttoA. is important. Articles and notices concern: 
Pascal philosophy, the use of Pascal as a teaching tool, uses of 
Pascal at different computer installations, portable (applications) 
program exchange, how to promote Pascal usage at your computer 
installation, and important events (meetings, publication of new books, 
etc.). 

Implementation information for the programming language Pascal on different 

computer systems is provided in the Hm^lojttiVt out of the necessity 
to spread the use of Pascal. This includes contacts for maintainers, 
documentors, and distributors of a given implementation as well as 
where to send bug reports. Both qualitative and quantitative 
descriptions for a given implementation are 'publietzed. Proposed 
extensions to Standard Pascal for users of a given implementation are 
aired. Announcements are made of the availability of new program 
writing tools for a Pascal environment. 

Miscellaneous features include bibliographies, questionaires, and membership lists. 

ALL WRITTEN INFORMATION FOR THE Meu;^£ette/L is EASIER TO PRINT IF YOU 
WILL TYPE ALL MATERIAL 1^ OR DOUBLE SPACED SO THAT IT IS IN CAMERA- 
READY / photo-reducible'' form for the printer. remember^ all LETTERS 
TO ME WILL BE PRINTED IN THE nzl^^6tztttK UNLESS THEY CONTAIN A REQUEST 
TO THE CONTRARY. AN OVERRIDING GUIDE SEEN IN AN OLD ^M MAGAZINE 
APPLIES: " a€£ tkz nmi> that jit^, u)t pni^nt V^ > Andy Mickel, editor, August 5, 1976. 

John P. Strait, assoc. editor 
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UNIVERSITY OF MINNESOTA 

TWIN CITIES 



University Computer Center 

227 Experimental Engineering Building 

Minneapolis, Minnesota 55455 

(612) 376-7290 



PART I - In General 

Hi I And here is the first issue of the Pascal User's Group Vcaaal Nm^lattoJi . 
Very important: read POLICY on inside front cover. My editorial comments appear 
throughout the newsletter as Pascal style comments enclosed in "(*" and "*)". At 
this writing, PUG has a phenomenal 317 members. We have grown steadily since we 
began soliciting members in April. Some members have had so much faith in our 
continued existence that they have signed up for several years I 

There were two members who suggested that the word "user's" in PUG's name 
be changed to "users'" instead (see HERE AND THERE). To me it doesn't really matter. 
I could argue that PUG belongs to each individual member - it is more like a 
federation. 

For the record here are some of the events which led to PUG. We have much 
to owe George Richmond, of the University of Colorado (and Lyle B. Smith before him) 
for tending the fire nearly alone in North America for several years. George began 
Pascal Hmi>t(itt2A with issues in January and May of 1974 and February, 1975. In the 
third (February) issue he sent a sort of "SOS" to all persons listening: "...there 
is a need for a strong Pascal Users Group... the present mechanism for distribution 
and support will become more inadequate." After talking with other Pascal ers - 
namely Alfred Towel! at Indiana University, Dave Tarabar at the University of 
Massachusetts, and George - John Strait and I sent a letter to the editor in July, 
1975 stating our desire to participate in a User's Group. 

A year ago at ACM '75 in Minneapolis, a Pascal User's Group meeting was 
held spontaneously on October 22 at the urging of Richard Cichelli of Lehigh 
University and R. Warren Johnson of St. Cloud State University. Thirty-five persons 
attended and we decided to work toward a more permanent organization using Vojid.al 
h!QM}6lQ.ttm as a communications medium. I organized a mailing list and little 
happened. When I talked to George in December about the newsletter editorship, 
he said he wanted to do one more issue himself. So we planned our first issue for 
April '76. 

But as things turned out, George was delayed by terrific work loads at his 
computer center which incidentally hurt his other Pascal duties. After a few months 
we decided to organize more thoroughly and push the date for our first newsletter 
to September. In April and May we sent out 400 general solicitations to join PUG 

EDITOR'S CONTRIBUTION 



to computer centers and computer science departments at universities in the United 
States and Canada. We also placed an announcement in SIGPLAN Notices for May. In 
the mean time we were hoping that George's Newsletter #4 would appear to announce 
the transition to the persons on his already established mailing list of more than 
500. 

As it stands, George's last newsletter will be appearing just before this 
one, and to avoid the complication of excessive requests for back issues and 
duplicating material, we will purchase copies of his newsletter to send as a free 
"bonus extra" to persons in the United States and Canada who are not on George's 
list. Persons on Georges list who are not PUG members should read the transition 
information in Newsletter #4 and join PUG hopefully. I estimate we will gain at 
least another hundred members this way. 

Those of you who received a receipt for membership may be interested that 
the pug dog is a sort of joke - I for one would not feel secure having such a 
weakling for my guardian (a sort of a pig of a pug the way it was drawn). Actually 
Pascal User's Group is a shoestring operation run right now in the spare time of a 
couple of systems programmers. The important implication here is that John and 1 
cannot be yery responsive to individual requests - all we can promise to do is the 
newsletter and rest assured we'll print everything that comes to our attention. 

With this issue of the newsletter we hope things begin to improve, because 
I realize all is not good with Pascal right now. I can tell from PUG's mail. 
Confusion reigns. But I'm an optimist - we'll pull through. 

Next issue I will supply an accounting of our costs so far. (In the post- 
Watergate spirit of full disclosure.) 

Now I must give credit where credit is due for PUG and Pascal N2W6leXtQ.n. #5: 

John Eisenberg for his idea of collecting phone numbers, 

Richard Cichelli for suggesting guidelines for the cost of membership, 

Wilhelm Burger for suggesting user's group memberships rather than 

newsletter subscriptions, 
Al Towel 1 for miscellaneous encouragement and suggestions, 
SICDOC Systems Documentation Newsletter for the idea for an "ALL PURPOSE 

COUPON", 
Christi Mickel for doing the mass mailing of 400 and for processing 

memberships in PUG, 
Computers and People "Computer Directory and Buyer's Guide" for an organizing 

and reference tool , 
SIGPLAN Notices for publicity in their May issue, 
Les Kerr for the suggestion to print a roster of members in an early issue 

of the newsletter (see next issue), 
John Strait for creating the mailing list data base and for innumerable 

suggestions, 
Michael Schneider for helping design our cover letter and SIGPLAN announcement, 
James Dorr (editor of Indiana University's Random Bits ) for producing our 

front cover title, 
Niklaus Wirth and Urs Ammann for encouragement. 
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George Richmond and Jan Hurst for providing last minute transition suggestions 

in August, 
The computer center newsletters of Lawrence Berkeley Labs (Ed Fourt), the 

Middle-Illinois Computer Coop (Don Klett), Purdue University, and the 

University of Hinnesota for articles publicizing PUG, 
Twin Cities ACM's Bits and Bytes (Judith Kruntorad) for announcing PUG, 
and finally the University Computer Center, University of Minnesota for providing a 

warm home for PUG. 

PART II - Pascal at the University of Minnesota 

Our computer installation consists of a CDC Cyber 74 running large scale 
batch and 30 interactive terminals, and a CDC 6400 running 150-200 interactive 
terminals only. Pascal has been available here since summer of 1972 when a colleague 
of mine (and now PUG member) Steve Legenhausen suggested we obtain the Pascal compiler. 
Usage here has been boosted mainly by applying William Waite's principles for giving 
a language processor (organism) support at a computer installation (ecosystem). Now 
after the Computer Science Department's wery successful initial year of replacing 
FORTRAN with Pascal in its curriculum, usage is respectable. In the last fiscal year 
(July- June) at Minnesota the major FORTRAN compiler (MNF) was run 810,000 times on 
both machines; BASIC 477.000; Pascal (#3!) 103,000; FTN (CDC FORTRAN) 69,000; COBOL 
49,000; Assembler 44.000, SNOBOL 40,000; and etc. 

John Strait, Lawrence Liddiard and I have cooperated with Urs Ammann of ETH 
Zurich over the past year in producing the second release of Pascal 6000-3.4. We 
helped mainly in the effort to reduce core requirements for the compiler. Our group 
continues to maintain the compiler for the KRONOS/NOS operating system for CDC 6000/ 
Cyber 70,170 series machines and in fact several other sites run our version. The 
main changes have been for interactive access because 85% of Pascal's use here is 
interactive. We are now cooperating with George Richmond to make our mods for 
KRONOS/NOS available with the distributed version. 



Finally, confusion proliferates at to what the next developments will be 
and where implementations will come from. This situation should improve with the 
regular appearance of this newsletter. 

We all need to pull together to help remove a major obstacle to our being 
able to respectably use Pascal: its low percentage of usage in the world's computing, 
We can do it; it will happen. A major indicator is the "Pascal explosion" in the 
current computer science literature. 

I consider the IMPLEMENTATION NOTES section to be yery important. Here we 
will hope to find increasingly complete and usable information for spreading the 
"virus" of Standard Pascal. 



August 10. 1976 
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PART III - My Concerns 

As I mentioned earlier, all is not well with Pascal. Mainly, considering 
the design goals of the language (reiterated in the POLICY section inside the front 
cover) we are suffering. 

First, people continue to ignore the combination of these design goals 
when making suggested "improvements" to the language. These are the subject of 
several letters and comments which appear in this issue of the newsletter. 

Secondly, several bad implementations are being circulated and in turn are 
giving Pascal an unnecessary^bad reputation as 'a language. See IMPLEMENTATION NOTES. 
Also many implementors have taken the liberty to implement something significantly 
less than Standard Pascal and call it Pascal. What about portable software then? 
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CONFERENCES 

Pascal User's Group session at ACM '76 Wally Wedel , PUG member from the 

University of Texas at Austin will chair a PUG meeting at this year's ACM conference 
in Houston, Texas. The conference extends from Wednesday, October 20 to Friday, 
October 22 in the Hyatt Regency Hotel. Wally has made arrangements with the 
conference organizers and SIGPLAN; the exact time of the meeting will be printed 
in the schedule handed out at the conference on Wednesday. Proposed topics of 
discussion are: Interactive I/O conventions/Extended character set treatment/ 
Implementations and user experience with implementations/Documentation standards 
for variations. 

Pascal: Implementation and Application D. W. Barron has announced a two 

day Symposium organised by the Computer Studies Group, University of Southampton, 
United Kingdom during 24-25 March 1977. Sessions include: The language and its 
implementation/Pascal in systems programming/Pascal in research and education/ 
Pascal, the future. Well known authorities have been invited to speak. To receive 
further details when available - write to: Conference Secretary, Department of 
Mathematics, The University, Southampton, S09 5NH, United Kingdom. 

NEW BOOKS 

Algorithms + Data Structures = Programs by Niklaus Wirth, Prentice Hall, 1976, 

366 pages, hardcover, $15. 
A Primer on Structured Programming Using PASCAL by Richard Conway, David Cries, 
and E. C. Zimmerman, Winthrop Pub., 1976, 420 pages, paperbound. 
(*Note: for price write to PUG member Michael Meehan, Winthrop Pub., 
17 Dunster St., Cambridge, MA 02138.*) 
Introduction to Problem Solving and Programming with Pascal by 6. Michael Schneider, 
David Perl man, and Steven W. Weingart, Wiley, to be published in 1977. 
(*Note: for more info write to PUG member Michael Schneider, 
C. Sci . Dept., 114 Lind Hall, Univ. of Minnesota, Minneapolis, MN 
55455.*) 
Study Guide, Introduction to Computer Science by Kenneth L. Bowles, to be published. 
(*Note: for more info write to K. Bowles, Univ. of California, 
San Diego, La Jolla, CA 92093.*) 
Standard Pascal by J. W. Atwood, to be published. (*Note: for more info write to 
J. W. Atwood, Dept. of Comp. Sci., Sir George Williams Campus, 
Concordia Univ., Montreal, Quebec, Canada H3G 1M8.*) 



NEWS (alphabetical by last name) 

0- Beauf ays , Mathematiques Appliques, Universite Libre de Bruxelles, Bruxelles 
1050 Belgium (PUG member): "...we are using this language for teaching..." 

Scott Bertilson . RR 2, Spicer, MN 56288 (PUG member): "James Martinson and I are 
interested in microcomputer versions of Pascal, Pascal -S, or Concurrent Pascal" 

Albrecht Biedl , Institut fuer Softwaretechnik, Technische Universitat Berlin, 
1000 Berlin 10, Germany VSH 419 (PUG member): "I enclose copies of the PASCAL 
Jnfo we have published in 76 for a growing Pascal community at the Technical 
University of Berlin" (Numbers (1976-01-05), 1 (1976-02-26), 2 (1976-03-03), 
and 3 (1976-06-15)) 

Richard J. Cichelli , 901 Whittier Drive, Allentown, PA 18103 (PUG member): 
"What we need next is a program which reads up Pascal relocatible binaries and 
proposes overlay structures. It should report field lengths vs. various overlay 
alternatives. It really is about time that many of the clerical and record 
keeping tasks of programning be automated. Pascal users should have the best 
tools for program development. Do you have any suggestions in this area? (source 
and object file maintenance systems?) 

"Pascal users accumulate 25% of all charges on Lehigh's system. 
"The last correspondence of the Zurich-Minnesota letters that I have was dated 
November 25. Incidentally I think your letters should be more supportive to 
them. I feel that reasoned discussion with the community at large is the way to 
resolve some of these technical issues. Let Wirth and Hoare set the principles 
and ideals. Help Urs with his implementations and help create a forum for 
information interchange. We need to promote growth and change in an environment 
of mutual cooperation. 

"I believe any changes in implementation should be discussed with the users. Only 
organizers like you can facilitate the necessary communication. Note, I am not 
opposed to changes per se. If Pascal 6000 is to grow it must be a living, changing 
language. Rational change is possible only with the cooperation of the user 
community. 

"I like the name PUG. See how Wirth likes it. 

"I would like to see a user profile on PUG members: usage statistics, application 
environments, etc." 

Kurt Cockrum , 3398 Utah, Riverside, CA 92507 (PUG member): "I am particularly 
' interested in microprocessor (8080) implementations of Pascal." 
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HERE AND THERE WITH PASCAL ^'^^^^ ^^^^ MEMBERS> conferences^ new books, applications programs, ETC.) 



^- ^- Dickerson , School of Information Sciences, The Hatfield Polytechnic, 
Hatfield ALIO 9AB, United Kingdom (PUG member): "...we have a DEC 10 and use 
Nagel's (Hamburg) Pascal compilers. We are going to use Pascal as a first 
language for our B.Sc. in computer science (we have about 200 undergraduates 
on the degree)." 

Doug Dyment , 6442 Imperial Ave. W. Vancouver, B.C. V7W 205 Canada (PUG member): 
"My current interest in Pascal is an evaluation of its use as a system 
programming language. Good luck with the new group." 

Gerhard Friesland , Institut Fuer Informatik, Universitat Hamburg, 2 Hamburg 13, 

Germany (PUG member): "My interest is based on participation in the transport 

of a compiler onto the POP- 10 and current work on an interactive programming 
system, implemented via a compiler-compiler in Pascal." 

^^^^ Grit , Dept of Computer Science, Colorado State University, Fort Collins, 
CO 80523 (PUG member): "We're using Pascal to a limited extent (e.g. the 
compiler course). We are still stuck with teaching FORTRAN in our intro course, 
but our approach to FORTRAN is to teach them to develop problem solutions in a 
"thinking" language (which just happens to have Pascal control constructs) and 
them how to mechanically go from there to FORTRAN. 

"Another approach we hope to try is to teach Pascal for 8-9 weeks of the semester, 
then teach FORTRAN as a restrictive subset. 

"We have a student doing a summer project to put up Hansen's sequestial Pascal 
and his concurrent Pascal. We are getting a Cyber 18 this fall and plan to 
make it a Pascal machine." 

Sam Gulden, Dept of Mathematics, Lehigh University, Bethlehem, PA 18015 (PUG member): 
"Enclosed you will find applications from some of the members of our local 
Pascal Users Group. I am looking forward to the newsletter having been an 
enthusiastic Pascal user for about two years. We have used Pascal here to tackle 
some interesting mathematical problems. Perhaps we will report on them in the 
future." 

Michael Hagerty , 18 Hamilton Road, Arlington MA 02174 (PUG member): "Our work 
is with large data bases (200 cards for each of 300000 people). Processing is 
constrained by I/O and takes 20000 seconds on a CDC6400. We are therefore 
implementing GETBUF and PUTBUF routines to read more data at a time from tapes. 
"I am working on a paper which will define an additional structure for Pascal, 
the environment. This concept will allow the easy integration of a form of 
overlays, a more dynamic (moving FL) system, as well as the inclusion of a 
"systems text" for compilation. Once completed, I will send you a copy. The 



implementation will have to wait until I can find time to sketch out the loader 

needed to handle multiple environments. 

"Included in our implementation of Pascal is a copy of Michael Condict's 

re formatter.. ..I feel that one function of PUG would be to see that software 

written in Pascal is made available to the larger community..." 

Charles Hedrick , 183 Corrmerce West. University of Illinois, Urbana, IL 61801 (PUG 
member): "If we are going to have a language which is implemented and maintained 
entirely by users, as seems likely (no computer manufacturers have made offers to 
do it), it is clear that there should be at least a lot of communication between 
people doing work on the same machine. Preferable would be to have one person 
for each machine maintain a common version which gets everybody's bug fixes. 
Notice I say bug fixes and not enhancements or extensions. To keep track of all 
of these would be more work, and would probably detract from the stability of the 
system. Alas, I have no candidate to propose at the U. of I. for this. I am not 
a full-time programmer (I teach and do research as an asst. prof, and don't have 
time for such things). The person who works on our local version has been unable 
to get funding for Pascal work, and may well be switched to a system other than 
the DEC 10 anyway. (We are in the process of getting a new computer system.)" 

William C. Hopkins , 207 Ridgewood Drive, Amherst NY 14226 (PUG member): "Note: 
as there are several users, shouldn't the name be "Pascal Users' Group" ?" 

Ed Katz , Computer Science Dept., Box 4-4330, USL Station, University of SW 
Louisiana, Lafayette, LA 70504 (PUG member): "We had such success teaching 
Pascal -S last year on our Honeywell Multics system, that we plan to use a full 
implementation this year." 

Thomas A. Keen an . Software Systems Science, Division of Mathematical and Computer 

Sciences, National Science Foundation, Washington, DC 20550 (PUG member): 

"Good luck with your venture." 
Leslie R. Kerr , David L. Johnson and Associates, 10545 Woodhaven Lane, Bellvue, WA 

98004 (PUG member): "I would like to thank you for taking the initiative in 

founding a Pascal user's group, which I feel is long overdue. I hope I will be 

able to contribute in some way to its success. 

"I would like to see the roster of PUG members published in an early issue of the 

Newsletter." 

Oan Kok , Mathematisch Centrum, Tweede Boerhaavestraat 49, Amsterdam, The Netherlands 
"The Mathematical Centre Amsterdam (Mathematisch Centrum) is engaged in 
constructing a numerical mathematics procedure library in Pascal, to be available 

on the CDC Cyber 73-28 computer of the Academic Computer Centre at Amsterdam." 
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0- Lecarme , I.M.A.N., Universite de Nice, Pare Valrose, 05034 Nice Cedex, France 
(PUG member): "I am planning to create a smaller but similar group for the 
French speaking community, and I will be very happy to maintain good communication 
with you." 

Chris Martin , Computing Services, The Hicks Building, University of Sheffield, 
Sheffield SIO 2TN United Kingdom (PUG member): "We have the Belfast compiler on 
an ICL 1900 and though at the moment it isn't very widely used, I expect the rush 
will start when I get the Montreal Compiler Writing System installed." 

Joseph Mezzaroba , Dept of Mathematics, Lehigh University, Bethlehem, PA 18015 (PUG 
member): "I have been using Pascal (as implemented for the CDC-6400), here at 
Lehigh University for the past two years. I will be teaching Computer Science at 
Villanova University starting in September and I would like to get either a Pascal 
or ALGOL-W Compiler on Villanova's IBM 370." 

Carlton Mills , Mills International, 203 North Gregory, Urbana, IL 61801 (PUG member): 
"Has anybody defined any structured escape language constructs? Has anybody 
defined any macro facilities? We are about to." 

Judy Mull ins . Department of Mathematics, The University, Southampton United Kingdom 
S09 5NH (PUG member): "I enclose ... $8 ... for two year's subscription to the 
Pascal Users' Group and Newsletter. This advance payment was prompted by the 

large banker's commission on small sums such as $4 

"Arising from this, I was wondering whether it would be useful or possible to a 
arrange some kind of branch of P.U.G. in the U.K. for collecting subscriptions. 
... a convenient and cheaper form of membership may encourage more members in the 
U.K. There are certainly many institutions using Pascal now, and interest is 
spreading.. . . 

"As co-organizer with Prof. Barron of the Pascal Symposium for next March, I 
could get the thing started. Others in our group are writing a Pascal compiler 
for ICL's new 2970 computer, so we shall always have a vested interest in Pascal." 

Maurice 0' Flaherty , 444 Merville Garden Village, Newtown Abbey, Co. Antrim, N. 
Ireland (PUG member): "I am at present finishing my thesis for an M. Sc. in 
Computer Science and Applications, and having used Pascal I would like to 
continue my interest in it." 

George Richmond , Computing Center, 3645 Marine St. University of Colorado, Boulder, 
CO 80309 (PUG member): "The Computer Science Dept. here will be converting to 
Pascal this fall, starting in the introductory courses." 



Steve Reisman , Clinical Systems Division, School of Denistry, University of 
Minnesota, Minneapolis, MN 55455 (PUG member): "We are using Pascal for 
scheduling and grading for the School of Denistry." 

Staffan Rombercjer , Scoputer Science, Royal Institute of Technology, S-10044 
Stockholm, Sweden (PUG member): "Here at the Computer Science Department of 
Royal Institute of Technology there is a growing interest in Pascal. We have 
access to the Pascal and Pasrel compiler's fgr DEC-10 from Hamburg and there are 
also compilers for PDP-11 and movements towards writing compilers for other 
computers." 

David Slocombe , The Globe and Mail, 444 Front St. West, Toronto, Ontario M5V 2S9 
Canada: "Although we don't now have a Pascal compiler (we intend to check out 
the Stony Brook implementation as soon as we have time), we have followed the 
development of the language almost from the beginning and two of us here have 
used Pascal as a design language for some years. It sure would be nice not to 
have to hand-compile!" 

N. Solntseff , Dept. of Applied Mathematics, McMaster University, Hamilton, Ontario 
Canada L8S 4K1 (PUG member): "I am interested in participating in the users' 
group and am willing to contribute my time in any capacity. 
"Incidentally, I would be happier if the title of the group were the more 
grammatical "Pascal Users' Group". " 

W. Richard Stevens , Kitt Peak National Observatory, P.O. Box 26732, Tucson, AZ 
85726: "Here at Kitt Peak I have just installed the 6000-3.4 compiler on our 
CDC 6400 and am currently trying to generate interest in the language. In 
addition, I would like to volunteer any services of myself to help the User's 
Group. 

"Will the User's Group have any affiliation with the current distribution center 
at the University of Colorado?" 

William Waite , Software Engineering Group, Dept. of Electrical Engineering, 
University of Colorado, Boulder, CO 80302: "Thank you for your invitation to 
join the Pascal User's Group. Lack of funds makes it impossible for me to accept 
personally;. . .You ask why PLAP was not written in Pascal. The answer is obvious - 
lack of portability. We have been attempting to cure this problem, as well as 
doing some research in intermediate language design. Unfortunately we have 
succeeded in the latter while the former still eludes us. The whole story is a 
sad one, resting upon the inadequacy of our tools. I believe that we will lick 
the problem eventually, but until I see the evidence I shall write portable 
programs in another language." 
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"I was interested that the Pascal usage at Minnesota has exceeded that of RUN 
and FTN. Have you been using it in an introductory course? We plan to do so 
next fall, and I would appreciate any comments you have. 

"It seems to me that one of the most difficult problems faced by Pascal is one 
that could be considered irrelevant: the ordering of multidimensional arrays. 
Since the language definition implies row-major order, it seems that Pascal- 
FORTRAN communication might be very difficult. How have you handled the problem 
when perverting FORTRAN library routines?" 

Wally Wedel_, Computation Center, University of Texas at Austin, Austin, TX 78712 
(PUG member): "We are running Nagel 's DEC-10 Pascal, Brinch Hansen PDP-11 Pascal, 
Wirth's CDC6000 Pascal. Wilhelm Burger has done extensive work on both the DEC-10 
and CDC6000 implementations." 



Lecture Notes in Computer Science, No. 16 

(*When purchasing, specify the "Springer Study Edition" - it's 35% cheaperl*) 
PASCAL - U5ER MAf^JUAL AND REPORT by K. Jensen and N. Wirth, Springer-Verlag, 

1974, 1975, 167 pages, paperbound. 
Corrections to 2nd Edition 



"setopCoutput) ;" 



p. 51, 1.16: "setap(autput)" 

p. 56. 1.-6: "fi** -» "f(i)» • 

"g(i+1)" -> "g(j+1)" 
"gi" - g(j) 

p. 63, rig,lQa: Number sequence should be reversed. 



p. 69, 1.23 

p. 77, 1.18 

p. 98, 1.10 

p. 102, 1.7 

1.20: 

p. 103, 1.-6: 
1.-7: 

p. 124, 1.-14 and l.~15: "14" ^ "15" 

p. 127, 1.27: "18. A" -» "4. A" 

"two" -♦ "to" 



"stricly" -» "strictly" 

move line 3 places to the left 

append " ' ;" 

last word should be "or" 
"bufffer" -♦ "buffer" 

"scaler" -♦ "scalar" 

"char, and alfa" -> "and char are listed" 



p. 133, 1.3: 

p. 135. 1.5: 
1.30: 

p. 140, 1.11: 

p. 158, 



"althought" 
"subtstitute" 



"although" 
* "substitute" 



"structure type" -» "structured type" 
delete lines -12... -8. 
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Additional Suggested Corrections 



September 26, 1975 University Computer Center 
University of Minnesota 



Page/Line , 

13/-3 "if" ^ "If" 

69/-8 "the readability" > "readability" 

72 /-3 "element in the array" > "component in the structure" 

81/2 "extent" •> "extend" 

117/ in the syntax chart for expression, change: 

1^ < ^ to <><=>= 

119/13 move the message right by 1 position 
126/-19 to -14 move the "i" index entries to the next page 
153/16 "(and at least once)" ^ "(at least once)" 
162/3 "end of line" ■> "end of line" 
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Designing Data Structures by Step-wise Refinement 

A Tutorial (*Note: by Richard J. Cichelli*) 

Keywords ; Data structures, step-wise refinement, top-down 
design, systematic programming, PASCAL. 

Abstract 

Dijkstra [l] and Wirth [2] have defined the principles 
of systematic programming. They illustrated these principles 
by designing programs whose control structures reflected 
hierarchical abstractions of their logic flow. In this paper^ 
systematic programming principles are applied to the design of 
a program's data structures. 

Overview 

This paper begins with a reexamination of the Queens 
problem: a traditional program design problem. An alternate data 
structure is devised for the program and relevant design issues 
and terminology are discussed. 

A step-wise, top-down design of the data structures for 
a Soma cube [3] solver is then presented. The data definitional 
capabilities of PASCAL [4] aid in the design process. 

The Queens Problem Revisited 

Both Dijkstra and Wirth use a traditional backtracking 
problem to illustrate systematic programming. The problem is to 
write a program which places eight hostile Queens on a chess board 
such that, no Queen threatens another. The programs are extended 
to find all 92 solutions. 



Following Dijkstra 's program, the main routine might be: 

begin initialize; generate end . 

Initialize clears the board and generate recursively calls itself 

to place a Queen on each column. 

procedure generate; 

var h: 0..7; 
begin 

for each__row h do 
begin 

if square_is_f ree then 
"Eegin place_queen__on__square; 

if board_full then print_solution else generate; 
remove_jqueen_from_3quare (♦ backtrack ♦) 
end 
end 
end ; 

Dijkstra tests whether a square is free by noting: 

1) for each column N (0^N^7)* generate only places 
one Queen, 

2) for each row H, the boolean array column Dfl is used 
to mark a row as taken^ and 

3) for the 30 diagonals, the boolean arrays u£[N-iil and 
down [n-hQ complete the masking. 

ISiese three boolean arrays are Involved in testing if 
a square is free^ placing a Queen, and removing a Queen. 

To improve the speed of the program we can augment 
Dijkstra 's data structures and, by having the prograim know more, 
trade space for time. Observe that the column , up , and down arrays 
are simply marking instances of the same type of thing. Each 
masks off a direction on the board. In total there are 46 such 
directions on the chess board - 16 for the rows and columns and 
30 for the up and down diagonals. 
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Since the mask for each square [n,h1 is a unique set, 
this loop invariant calculation can be done once in the initialization 
code, (See revised program in Figure 1.) 

The Soma Cube 

The Soma puzzle consists of seven pieces; six of the 
pieces are made by Joining four cubes together, and the remaining 
piece is made up of only three cubes. The problem is to fit the 
pieces together to form a 3x3x3 solution cube. There are 240 
unique solutions to the puzzle. (The seven pieces are shown in 
Figure 2.) 

It is evident that the simple backtracking algorithm 
which worked for the Queens problem will also work for the Soma 
cube. Pieces in the Soma cube are placed like Queens on the 
chess board. A piece is included in the solution cube only if 
It "fits". 

To find a solution, we start with an empty solution cube 
and place pieces one by one until all pieces are placed or the 
current piece does not fit. If the piece does not fit, the 
previously placed piece is removed and replaced elsewhere, and 
the search continues until a solution is found or the piece locations 
are exhausted. 

The difficulty here is that the search space is so 
large that efficient testing of whether a piece fits is essential 
for an effective program. The possible solution locations of 
any piece need only be calculated once if we have a data structure 
like the boardmask data structure in the Queens program. We can 
create such a data structure by top-down design methods. 



The Soma Cube Data Structure 

The Soma data structure is operated upon by two routines; 
the first initializes it, and the second generates solutions with 
it. Although it is composed of many parts, this data structure 
is properly viewed as a single named entity. It holds all the 
data relevant to the seven Soma pieces. In PASCAL we declare 

var pieces; array fpiecol of piecedescription; 
This declares pieces to hold the same type of information for 
each piece . Since we wish to treat each piece in the same way, 
this is the appropriate overall structure. 

Next we need to declare the types piece and 
piecedescription . There are seven pieces and so the declaration 

piece » 1. .7; 
is appropriate. 

For each piece the piecedescription must completely 
describe the information local to a piece. It will basically 
consist of a list of locations. The length of this list varies 
from piece to piece, and in addition, during backtracking we will 
need to know where we are in the list. Since these items are not 
of the same type, the record structure is needed: 

piecedescription = 

record 

llstlength, whereat: listsize: 
posltlonlist: array [listsizej of positions 

end ; 

We can postpone the calculation of the maximum listsize by 
declaring the type 

listsize a 0.,maxlist; 
Maxlist will be a declared constant. 
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Poaitionllst is declared an array of positions because 
we expect each possible description of the location of a piece 
to be of the same type. Since each piece will fill a set of 
locations in the solution cube, the declaration 

positions = set of locations; 
seems natural. There are 27 locations in the 3x3x3 solution 
cube. We thus declare 

locations « 1..27; 

To calculate maxlist we observe (usually with a little 
difficulty) that piece 1 can be placed in l44 unique orientations 
within the solution cube. It obviously can occupy more places 
than any other piece. 

The final list of declarations that we have built up 

appears below: 

const 

maxlist « 144; 
type 

piece « 1. .7; 
locations = 1..27; 
positions - set of locations; 
listsize = 0. .maxlist; (* one to spare ♦) 
piecedescription = 
record 

listlength, whereat: listsize; 
positionlist; array [listsize] of positions 
end ; 
var 

pieces: array [piece] of piecedescription; 
somacube: positions; 

How Will the Soma Program Work ? 

The first phase of the program will generate the piece 
descriptions. It will have to take each piece and rotate and 
translate it through all 27 locations. Duplicates should not 



be entered into the positionlist . As the positions are added to 
the positionlist , listlength is incremented. 

The backtracking phase begins after all positionlists 
are complete. For each piece, whereat (which is initialized to 
zero) is incremented from zero to listsize . It is the index to 
the positionlist of the position under examination. Pieces which 
fit are Joined into the somacube solution. The "fit" test is 
simply the set operation 

((positionlist [whereat] meet somacube) ec[ [] ) 
where [] is the empty set. To add in a piece which fits we write 

somacube :« positionlist [whereat] Join somacube; 

Piece removal during backtracking only requires set 
differences. (These operations are very fast in most PASCAL 
Implementations because hardware boolean logic is used for 
set operations. ) 

A complete version of a PASCAL Soma cube solver can be 
found in [5] . 

Summary 

We have shown that top-down design can be applied to 
complex problems in data structure design. It is hoped that 
the examples chosen illustrate the desirability of PASCAL-like 
type definitional capabilities for the top-down design of data 
structures. Languages without such type definitional capabilities 
are as deficient for data structure design as those which lack 
block control structures are for structured programming. 

(*Received 2/21/76*) 
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type 

«epoto7 • , t 7f 

dipectlons «= ,, asi 

d< f ect fonmask a set of d<rect<oni| 

powwask c array izerotol] of d< rect f onwaski 

boardmask s array Czeroto?] of rowmaskf 



J# k I <ntegefr 

aueen<pdx t ^ntegeff 

qgeeni 1 array [zerotoT] of zeroto7> 

mask I _ boardmeskf 

board t df rect < onmaakf 

procedure eener«t©> 
vef 

colhot I zerotoTf 
beq(R 

for col hgt ic to 7 do 

bcoH ( test square colhgt free } 

if ((board meet mask (col Hgt] [queenlndx] ) (• {]) then 
bee<n < set queen on square > 
queens [oueenindx] |s coihgtj 

board i= board jo<n mask Ccol hgt] Cqueeni ndx) f 
queen<ndx |s oueenlndx ♦ If 
( test if board U full ) 
<f (queenilndx s 8) then 
beg<n ( print board > 

for k IS a to 7 do wrIteC '^queensCk] f 2) f 
wrUe(eol) 
end else generate^ 
< remove queen from board > 
queenfndx 1= queen^ndx • l> 
board ta board - mask (col hgt] tqueenlndx] 
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bto<n < initialire the empty board > 
queen<ndx |» 0| 
board |b [] j 
fof j is to 7 do 
for k |8 to 7 do maskCjJtk] ta Cj# Cl5t(k-J ) ) , (23*(k* j) )] | 
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To the Editor: 

If the "science" of Comouter Science Is the exnerlmental Investls-atlon of 
algorithms, then effective r)ro.?:ra.'Timln>'- Is essential for the comouter scientist's 
comnutjnp- "laboratory" testinp:. Good orociramjninkr is an art, an enp^lneerint^ 
deslen art. Without It, the comouter scientist's Investigative nrocedures are 
susnect; with it, ccood desip-n helos clarify previously obscure alcjiorithms . 

Tn our software enelneerln^z; course at Lehlp;h University we have emphasized 
that the nrinclnies of ton-down desl^yn UU and structured Dro/sramminpi; 12'} aopiy 
not only to a nroeram's function code but also to its data structures. The 
data definitional canabillties of PASCAL [32 «^reatlv facilitate the ton-down 
formulation of data structure hierarchies. Good oroo-rams establish corresnondinc 
levels of abstraction between their control structures and their data structures. 
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The followlno: student Soma Cube nro^ram effectlvelv uses data and control 
hierarchies. Tn his enthusiasm for this software en?-lneerincr nroblem, Michael 
Condict rra'^p the transition from a desl^-n nrolect to the exnerlmental and 
scientific investloration of snace fillinp' alcrorithms . It is, to the best of 
our knowledfre, the ultimate Soma Cube Drop;ram (at least until next semester). 
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Figure 2 



Richard J, Clchelll 
Samuel L. Gulden 
Mathematics Department 
LehlKh University 



Another Solution to the Soma Cube Puzzle 
Michael N. Condict 
Lehlsrh University 

This Soma Cube C^l solution ctenerator evolved through a series of 
refinements from a nroe;ram similar to that of DeLoniz;'s f^l . The run time 
the first version was annroximateiv QO seconds on Lehicch University's CDC 6400. 
By examinin-^ the bound unfilled spaces (connected holes in the assembliner cube) 
and Drunin.3: when no niece would fit, the run time was reduced to about 30 seconds. 

The exDerlment was extended to Include McKeeman's C6] revised Soma 
alf.orithm which is based on Combinatory Theory considerations. Performance of 
the McKeeman alC':orithm is deoendent on the order in which nieces are selected 
for insertion. The rouc?:h execution times for the various alp;orlthms are Kiven 
below: 

Brute force 90 sec. 

Hole analysis orunintr 30 sec. 

McKeeman order { V, L,T,Z,S,R,Y j 60 sec. 

McKeeman order ( L. Y,S, R,T,Z, V) 15 sec. 

Combined McKeeman & hole analysis 13 sec. 
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CONST 

K332l»2>»9; 

TYPE 

CONPIGSETNOS* 0..28; 

CU3ETYP€S= (EOCe» CORNER. F*CE, CENTER)? 

comqinat":ns» O..Ut 

PI£CECONfI„. AT= 0Q00..K3321? 

A«<rsroi?coNFiG» o.,5o: 
Hntis* o,.2%j 

AXES* f ?fY,X) ; 

COa£S« 0..LASTCU8ET 

cuBESPi* -i..2r; 

PIECES* 1..7? 
PIEC£SP1» I. .8; 
POSITIONS* B..11.5? 
PIECcCUBESa l..i»? 
P1ECE«>0SITI0HS» SET OP 0..58; 
SMIFTS= -26..I.ASTCU8E; 
THEPIECES» APRAt t»I£C£5I OF 
RECORD 

PACKOI ARRAY tPOSITIONSl OF PIECEPOSITIONSJ 
UNPAC<EDI ARRAY fPIECECUBESl OF CU9£S; 
PRINTLISTI PIECiPCSiriONS; 
COMFIGCOHaiNATIONI 

ARRAY (C0N8INATI0NSJ OF CONFIGSETNOS? 
MAHEI char; 
FIRSTCONFIG, 
CURREMTCOHFIG, 
LASTCONFICI CONFIGSilNOS; 
ENO /'RECORD*/; 
TMECOBES" ARRAY (CU8ESP1J OF 
RECORD 

ALLOWEOSMIFTI SET OF 0..15; 
ROTATEABOUTI ARRAY lAXESJ OF CUBES; 
END /•RECORD'/; 
VAR 

FIOSTP05ITI0N, 
LASTPOSlTIONt ARRAY t CONFIGSETNOSI OF POSITIONS; 

NUHOtROFt ACRAV CCU9ETYP£S,C0NFI&5tTN0Sl OF Q,,kt 
C0H^*«UH'!ERl CCNaiNATIONS; 

COUHTOFI AFRAY (CUQETYPcSl OF 0..1<.; 
CU8£TYP£» CUBETYPES; 
NAXALLOWEOI AfcRAY ICUBETYPESl If 0..12; 
SOLUTIONNUIBERI INTEGER* 
TESTSHAOE. 
SOLUTIONSHAPEI PIEGEPOSITIONS; 
CUBEl CUBESPI ; 
PIECEI PIECESPi; 

soHti tmepieces; 

ONEI THECU3ES! 
MOLESIZEI holes; 

MOlECUBEt AR«AY(H0LES1 OF CUBESPi; 
TYPEOFI AJyPAY ICUBESI OF CJBETYPES; 
ROfATEVALUeSI ARRAY C AXES tCU'iES 1 OF ^UBES; 
PIECEVALUESt A<^<?AY (PIECES, PIECECUBESl OF CUBES; 
NAlEVALOESt AkRAY (PIECES 1 OF CHAR; 
*0JAC£NTTO« ARRAY tCUBESPlJ OF 
RECORD 

NUMBcRAOJSIOESi SIDES; 

keigm80ringi array (sidesl of cubespij 
cubesurrounoedl piecipositions ; 
end; 

VALUE 

TYPEOFa 

CC0RN£R,CD<;E. CORNER, EOGE .FACE. EDGE, CORNER, EDGE .CORNER, 
EDGE, FACE. EOCE, FACE .CENTER, FACE, EDGE, FACE, EDGE. 
CORNER, EDGE, CORNER, EDGE .FACE, EDGE, CORNER, EDGE .CORNER! J 
ROTATEVALUES* 
( 6. 5, 0, 7, kt 1, S, 5. 2, 
15,12, 9, 16, 13. 10, 17, I*, 11. 
2'4, 21, 18, 25, 22, 19.26. 2 3.26. 
2.11, 2a, 5,1<,.23, 8,17.26, 
ltl0,19, 4,13.22, 7.16.25. 
a, 9,15, 3,12,21, 6.15.2<». 
IS. 19, 20. 9.10.11. 0. 1. 2. 
21.22.25.12. 13, IW, 3, *►. 5 , . 
2%, 25, 26. 15.16. 17, 6, 7, 9); 
PIECEYALUES* 
f 0, 1, <», 7. 
9.18,19,21. 
10,11.2a«23. 
10.11,13.20. 
1, 3. <*. 7. 
8. 1. <*, 5. 
1. 3. <». (,); 
NAN£fALU£S= <=L=, =Y=, =S=. =R=. =T=, =Z=, iVilJ 

aojacentto= 

/•cube ; aoi neighbors filler •/ 

/• ,•/ 

•» -1 « (8. C,l)*8,8,0.e»«« 

V «- 3* 1. 3, 9« 0,0,0.8, 

t * kt 0. 2. ^.10. ft. 0.0, 

#2*3. 1. 5.11. 0.0, a, 0* 

•» 3 ♦ <>« 0. <»• 6.12. 0.0.0, 

" <» « 5. 1. 3. 5, 7.13, 0,0, 

•* 5 «> <»• 2. %. 8,1%, 0.0,0. 

#6*3. 3. 7, 15. 0.0.0. a. 

•• 7 * %, >., 6* 8. 16. a. 0*0, 

- 8 * 3, 5. 7. 17. C, 0,0.0, 
•• 9 * t», 8. 10,12.18. 0.0.0. 

# 19 * 5, 1, 9,11,13.19. 0.0, 

<• It * i». 2. 10. lif,20. O.J.O. 

•» 12 ♦ 5, i, 9, 13.15.21. 0.0, 

<• 13 ♦ 6, I..10. 12.1'.. 16,22, 0, 

- 1*. ♦ 5. 5,li,l!, 17,23, 0,8, 

# I': « <*• 6.12, 16. 2<*, 0,3,0, 

# 16 ♦ 5, 7,13,15,17, 25, 0.0, 

>* 17 ♦ (t, 8, It., 16, 26, 0,0,0* 

# 11 ♦ 3, 9, 1?,?1, 0,0,8,0, 

# 19 * «•, 10. 18,20.22. 0,3,«. 

•* 28 * 3. 11. 19, 23. 0.0,0,8* 

«• 21 * 4. 12, IS. 22, 2<., 0,3,8, 

# 22 ♦ 5, 13,19,21,23,25, 3 ,0, 

# 23 * «♦. 1«.,20.2?. 26. ,ii.O, 

•» 2i» « 3, 15,21. 25, .3.0.3* 

# 25 * (*. le.22.2(*.26, C.0.8* 

•• 26 « 1* 17,23,25. ,0*8,a, 

•» 27 ♦ 1* 27, i ,8*0.6,8.8M 



PfOCEOURE PRINTSPTtWOROt «»I ECEPOSIT IONS» ; 
VAR II 0..58t 
BEGIN 

MRITEI=t=i; 

ic- MORO ISNT (1 THEN 

BEGIN 

11*0; WHILE NOT IX IN woROi DO i»=r*i; 

MRITEfII2»; 

FOR It*I»l TO 58 00 IF I IN WORD THEM WRITE (: ,=, H 2) ; 
ENO /'IFt !•/; 
WRITE(=J=); 
END /"pRINTSET'/; 



fHlOCEOURE iNlTIALIZEVARIAatES; 

VAR AXIS! axes; 

BEGIN 

FOR PIECElsl TO 7 00 WITH SONACPIECEJ DO 
BEGIN 

MANEl»NAHeVALU£S(PIECEl? 
FOR CUBEI»1 TO k 00 

UNPACKEOCCUBEIlsPIECEVALUEStPIECE.CUBEU 
ENO /'^OR PIECE'/; 
F0« AXIStsZ TO X DO 

FOR CUBEisC TO LASTCUBE 00 «ITH ONEtCUBEl 00 
RCTATEAaOUT(AXISlt»ROTAT£VALJES(AXlS,CJBEJ; 
PI£CEt»i; S0LUTI0NSMAPEI=( i; SOLUriONNUH3ERI»0; 
MAXALt.OMEDtE0GEH = 12; HAXALLOHEDC "^ACE 1 «s6? 
HAXALLOMeO(COKNERJ«=8; MAXAlLOMEOC CENTER) t*i; 
ENO /'INITIALIZEVARIABLES'/; 



PROCEDURE FINOALLPIECEBOSITIONS; 
VAR PIECEI pieces; 

lESTPos.PcsiTioNi positions; 

TRANSLATION! CUBESPI ; 

ROTATION! 0..2I,; 

TEHPORARYPIECEI PIECEPOSITIONSf 

CONFK^URATIONSETNOI CONFIGSETNOS; 

CONFIGTYPEI PIcCECONFIGURATIONS; 

COMF1 GPCS IT lONI AHTSFORCONFIGURATION; 

SORTECPCSITIONI AkRAY t PIECECONFISURATIONS, AHTSFORCONFIGURl 
OF PIECEPOSITIONS; 

TESTCONFIGI PIECECONFIGURATIONS; 

NUNBERPOSITIONSFORI ARRAY C PIECtCONFI&URATIONSI OF POSITIONS? 



PROCEDURE ROTATE (MIAXESU 
VAR CUBEl 1,.«»; 
BEGIN 

FOR CU8E« = 1 TO i. DO WITH S0NA(PIECE1 DO 
NHH ONEtUNPAC>CE0(CUaEll 00 

UNPACKEOl CUBEl MROTATcABOUriNi; 
ENO /'ROTATE'/; 



FUNCTION PIECEFlTSlTRANSLATlONt CUBESPI) I BOOLEAN; 
VAR 

CUBEl PIECECUBES; 
XSHIFT,YSHIFT,ZSHIFTI -2. .2; 

SHiFTi shifts; 

TESTCUBEI cubes; 
LASTCU3EI CUBESPIJ 
BEGIN 

IF TRANSLATION=27 Th£N PIECEFITSlaTRUE ELSE 

NITM SO«A(PIECEI 00 

BEGIN 

TENPORARYPIEC£l=( i; PIECiFITSl*TRUE ; 

FOR CU8ETYP£I=E0GE TO CENTER DO COUNTOF CCUBETYPEJ «*«? 

SHIFT IsUNPACtCEOril-TRANSLAf ion; 

XSHlFTlsTRANSuATION HOO 3 

UNPACtCEOdl NOD 3; 
YSMlFTl»irRANSLATION OIV 3) KOO 3 

(UNPACKEOdl OIV 3) NOD 3; 
ZSHlFTt*TRANSLATION OIV 9 

UNPACKEOtlJ OIV 9; 
LASTCUBEI»27; 
FOR CUBElsl TO k 03 
KHH ONEtUNPACKEDlCUBEn DO 

IF N0TI(XSHIFT»2,YSHIFT»7.23HIFT«'12J L£ 
ALLOWEOSMIFT) THEN PIECEFITStsFALSE 
ELSE 

BEGIN 

TESTCU8EI«UNPACKE0(CUBE1 • SHIFT; 
IF TESTCUOE ISNT LASTCUBE THEN 
BEGIN 

C0UNT0FtTYPEOFtTESTCUBtllt« 

C0UNT0F(TYPE0F(T£STCU8En ♦ i; 
TEHPORARYPI£Cc»«TEHP0RARYPIECc 
JOIN ITESTCUBEi; 
ENO /'IF TESTCUBE'/; 
LASTCU8EI»TESTCU8E; 
ENO /'IF'/; 
ENO /'ELSE'/; 
ENO /'PIECEFITS'/; 



PROCEDURE FINOALLOWEDSHIFTS; 
VAR CUBE! cubes; 

AXISSHIFT.LIMITSI -2.. 2; 
SETINOEXI 2. .12; 

Axisi axes; 

BEGIN 

FOR CUBE«»0 TO. 26 DO 
KITH ONECCUBE) 00 
BEGIN 

ALLOWEOSHIFTIst 15 
FOR AXIS»*Z TO X 00 
BEGIN 

CASE AXIS OF 

XI BEGIN LIHITSI = C:JBE NOD 3; SETIKOEXIs? ENO; 

Yl BET.IN LIHITSI = CU3E OIV 3 HOO 3; 5F.TINOEXI = 7 ENO; 

Zl HEGIN LIHITSI'CJBE DIV 9; SETIN3£Xlai2 £««0; 

EHU /•ctsf/; 

F0« AxrSS^rFTls -LiHiTi TO (2-LIHlTE) 00 
ALLOWEOS.ITFTI* 

ALL3»»E0SHIFT JOIN t AXI SSHIFT*SETI NOEX 1 ; 
ENO /'FOR AXIS'/; 
ENO /'FOR CU=>E'/{ 
ENO /'FIMO ALLCHEOSHIFTS'/; 
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(»Lt POSS. COMriGliR.»=l > 



?€CIM /•riNl3ALLPIECEP0SITI0MS»/ 

rrNOAuiiOWEosMrFTsj 

CONFIC'JP«TIONSETNOI = 0? 
M<ITE«£Oi,= lTHe SET C<P» ISI: 
M<ITE«t C 

^■iiTfe«EOL»; MEomnuTPun; 

FOR PIECEMl TO 7 00 
HITh S0M4CPIECE1 00 
BCCIH 

FOR CO»*^IGTyPE«»0000 TO K312i 00 

NUMBE«iP0SITIOf6FORtCOHFIGTYPill = 0; 
POSITIONIsC; 

FOk POTATIONUl TO Zh 00 
BEGIN 

TR»MSL*TION|aO; 

WHILE NOT PIECEFITStTRANSLATlOM) 00 

TRANSLATION! »TRANSLATlOM»i; 
IF TRANSLATION LT 27 THEM 
BEGIN 

P»CK0tPOSITION»lll«TENPOR*RrPIECE? 

TESTPOSl»U 

V*MILE TEMPORARYPIECE ISNT PACKOf TESTPOS 1 DO 

T£STPOSl = TESTPOS»n 
IF TESTPOS » POSITIONfl THEN 

FOR TRANSLATIOMIsTRANSLATION TO 26 DO 
IF PIEC£FITS(TRANSLATIONI THEN 
BEGIN 

CONFIGTYPEI'O; 
POSITlONIaPOSITIONfi: 
PACKOCPOSiriONll'TEl'PORARTPIECej 
FOR CU3ETYPEI=E0GE TO CENTER DO 
CONFICTYP£l»CONFIGTyP£»«» ♦ 

COUNTOFCCUaETYPEi; 
MUHBERPOSITIONSFORC CONFIGTYPEl l» 

NJMaERPOSITIONSFORtCONFIGTYPEI ♦ I? 
S0RTEGPOSITI0N(C0NFIGTYPE.NUH9ERPOSiriONSF0R 
CCONFIGTYPEII IS TEHPORARYPIECE ? 
ENO /•If PIECEFITS, FOR TRANS« , IF TESTPOS*/ 
EMO /'IF TRANSLATION*/; 
ROTATEfZI ; 

IF ROTATION MOO «» I S TKEN ROTAT£fY»; 
IF POTATION IS 16 THEN ROTATEU*; 
IF DOTATION IS 20 TmEN R3TATt(YI? 
ENO /•FOR ROTATION*/; 
FI«STCONFICI=CONFIGURATlONS£TNO»i; 
POSITICNI^O; 
FOR CONFICTYPEI«00C0 TO K3321 DO 

IF NUMBERPOSiriONSFORCCONFIGTYPEl CI THEM 
3EGIM 

t£stconfig»*cqnfigtype; 

CONFIGURATIONSETNOI*CONFIGJRATIONSETMO ♦■ t; 
«RITEI= EL"). NO. =, CONFI6URATSETNOI2.il l=»l 

FOP CU3ETYPEMCENTER OOMNTO EOGE 00 
BEGIN 

NUMS£i<0F{CU8ETYPf .CONFIGUaftTIONSETMOJ 

l»TE3TC0NFIG MOO *»? 

«PITEIITESTCONFIG MOO (i)t2, = ,=); 

TESTCONFIGl'TESTCONiflG OIW «»5 
EMO; 

WHITEI = Jr,EOLI? NEOR f OUTPUT J ? 
COV IGPOSITlONlai; 

FIRSTPOSITIONrCONFIGURATIONSETN01«=POSITION ♦ i; 
FOR POSITIONlsPOSITIONH TO (POSITION ♦ 

NUMBS '.POSIT I ONSFOR£CONFIiTYPE II 00 
^EGIN 

PACKOCPOSITIONl •« 

sorteopositionf sonfigtype.configpositioku 
configp0slti0ni=configpositi0n*i; 
end; 

LASrP0SiriONCC0MFIGURATI0NS£TNOl««POSITIOM; 
end /'IF NUH^iERPOSITONSFOR*/; 
LASTCOHFIGI'CONFIGURATIONSETNO; 
WRITE!: =1? 

MRITE(HAHE,= PIECE HAS = , LASTPOSIT lONtCOKFICURATIONSETMOl Hi , 

= POSITIONS. = .EOL): 
WEORrCUTPUT} ; 
EHO /'FOR PIECE*/: 

FOR COMFIGTVPEl=SOMAt ll.FrRSTCONFIG TO SOMA( 1 J.L ASTCOMFIG 00 
LASTPQSITIONrCONFIGTYOEJt-FHSTPOSITIONCCONFIGTYPEU 
ENO /•FINOALLPIECEPOSITIONS*/; 



PROCECURE FIMCH0LEATICU8EI CU3ESP1>; 
VAR SIDEI SIOES; 
BEGIN 

TeSTSHAP£l=TESTSHAP£ JOIN (CUBE)? 

HOLESIZ£l=MOLESIZE*i; 

HOLECU9£(HOLESI7£ IIsCUBE; 

WITH AOjACENTTOtCUBEl 00 

IF NOT (CU-JESURROUNOEO LE T£ST5HAP£| THEN 

FOR SI0EI=1 TO NUH9S(?A0JSIOES DO 

If NOT (NEICMSORINGtSIOEl IM I£SrS>«APEI 
THEN FINOHOL£AT(N£IGH30RING(SIOE1) ; 
END /•FiNOHOLEAf/; 



PROCEDURE FINOSURPOUNOEOOUBEPOSITIONS; 
VAR SIDE t sides; 
BEGIN 

FOR CUBElsO TO 27 00 
NITM AOJACENTTOCCUSEI 00 
BEGIN 

CU3ESURRCUN0£DI=(i; 

F0<? SIC£l = l TO NUM8ERA0JSI0ES 00 

CU8£SU«»R0UMD£0I=CU9ESURR0UNCE3 JOIN t N£ IGHBORINGI SIDE 1 1 1 
ENO /**^CR CUBE*/; 
ENO /•FiNOSUfiPOUNOEOCUBEPOSITIONS*/; 



PROCEDURE FINDALLCONFICURATIONC 
VAO 

CONFIGURATIONSETNOI CONFI 
C0M8INATI0NVALI0I BOOL 
BEGIN 

NIIM SOHACPIECEl DO 

FOR CONFIGURATIONSETNO 
BEGIN 

C0M9INATI0NVALI0I»T 
FOR CUBETYPEIxEDGE 
8 EC IN 

COUNTOFf CUBE TYPE 

MUMBEROFtCUBE 

IF COUNTOFtCUBET 

C0M9INATI0'<VA 

EMOt 

IF C0M8INATI0NVALI0 
BEGIN 

PIECEI»PIECE*-i; 
CURRENTCONFIGl=C 
IF PIECE « a THE 
ELSE FINOALLCOMF 
PIECEI»PIECE-tt 
EMO? 

FOR CUBETYPElsEOGc 
COUNTOFtCUBETYPt 
- NUM8ER0 
END /•FOF*/J 
EMO /»FINOALLCONFZGURATIONCO< 



OHBINATIONS; 
GSETNOS; 



l=firstcosfig to lastconfig 00 

rue; 

to center 00 

ll«COJNTOFICUBETYPEl» 

type t configurationsetnoi; 

ypej gt maxallohtotcubetype} them 

lioisfalse; 



THEN 



ONFIGURATIONSETNO; 
N STOREOPELEMENT 
IGURATIONCOMBINATIONS; 



TO CENTER DO 

»«C0JNT0FrcU8ETYP£l 
Ft CCBETYPE* CONFIGURATIONSETNOI: 

MOINATIONS*/; 



PROCEDURE PRINTSOLUTIOn; 
VAR PIECEt pieces; 
BEGIN 

solutionnu»bepi=solutionnumber»i; 

W4ITEfr S0L. = .S0LUTI0WUM3£RI<*»; 
FOR PIECE 1 = 1 TO 7 00 
WITH SOMAtPIECEl CO 
BEGIN 

WRITEC5 =.NAME,=«=>; 

PRINTSET<PRINTLIST>; 
ENO /*r<3H PIECE*/; 
MRlTEtEOLi; WEOR{OUTPUTi; 

EMO /•PRINTSOLUTION*/; 



wjocEDuRE generate; 

VAR 

HOLEISNOTFILLABLEI BOOLEAN; 
TESTPieCEl PIECEPOSITIONS; 

posiTioNi positions; 

BEGIN 

WITH SOMAtPIECEl DO 

FOR POSITION l» FIRSTPOSITIONtCONFIGCOMBlNATlOMCCOMBNUMBERU 

TO LASTPOSITIONICONFIGCOMBINATIONICOMBNUKBERII 00 
3ECIH 

TESTPIECElsPACKOtPOSITIONi; 

IF SOLUTIONSHAPE MEET TESTPIECE IS (1 THEN 

BEGIN 

TESTShAPEI»SOlUTIONSHAPE JOIN TESTPIECE? 

CUBEl»-i; 

REPEAT 

REPEAT CUBElaCUBE*! 

UNTIL NOT CCUBE IN TESTSHAPEIt 

M0LcSiz£i«e; 

FINOHOLEAKCUBE* ? 
IF HOLES IZe IS 3 THEN 
HOLEISN0TFILLA3LE t* 

<H0LfeCU8Et21 - HOLECJBEtlll » 
fH0LECU8E( 31 - HOLEGUBEtZll 
aSE MOLtISNOTFILLABL£l» HOLESIZE MOO k IN (1,21? 
UNTIL HOLE ISNOT FILL able; 
IF CUBE IS 27 THEN 
BEGIN 

PKINTLISTI-TESTPIECE? 

SOLUTIONSHAPE isSOLUTIONSHAPE JOIN TESTPIECE? 
PIECEl»PIEC£»i; 

IF PIECE IS 8 THEN PRINTSOtUTION ELSE GENERATE? 
PIECElxPIECE-i; 

SOLUTIONSMAPEI'SOLUTIONSHAPE - TESTPIECE? 
ENO /•If CUBE IS Z7^/ 
END /•IF*/ 
ENO /•FOR*/ 
ENO /•GENERATE*/; 



SECIM 

IMITIALIZEVARIABLES; 

FINDALLPIECE POSIT IONS? 

COMBNUMBERI'C? 

FOR CUBETYPEI^EDGE TO CENTER 00 COUNT 0FCCU3ETYPE ) l«0 ; 

NRITclEOL.ElTHE SET D(PI IS«=.EOL»; 

HEORIOUTPUTi; 

FINDALLCONFIGURATIONCONBINATIONS; 

FINOSURROUNOEOCUBEPOSITIONS; 

HRITE(=1=.E0L»; 

FOR COMBNUMBERIeCOMBNUMBER OOMNTO 1 00 GEMERATEI 
ENO /*HAIM*/. 



pofjcEOu^c storeopelfhent: 
v«« PIECE! pieces; 

8f:GlH 

C'j»«iMUH.eeRi»ccHBnuM3£Rf i; 

W-<I7^.<£ tLEM.NO,=,COM3N'JM3E^« J. = l (tU 

«"0* •»:EC£» = 1 jo 7 00 KIT«< SOKAl-IECt.* 00 
^JEGTN 

':")Nr'GcnH?iN4Tii)Mt C0HO>fjH8r:Riiscu>iR£NTn0NF}:&; 

«RIT£<CU».'^CNTC0NFIGI2, i, il ; 

ENo; 

wRrT£« = j = ,t-oL»; 

ENO /•STCf 0P£L£M£NT*/; 
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frequency table of the following Corn'. 
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John E i senberg 
University of Delaware 



RANGE N 



100-90 
89-80 



25 
35 



(etc. ) 



One of the few things which* in ny opinion* wars the 
"synmetry" of Pascal is its lack of formatted input. I would 
like to present sone examples of "typical" basic conputer science 
problems which would be inconvenient or next to inpossible 
without the use of formatted input. 



Exanple X •' A survey has been given to 60 nenbers of 



Psych 100 class. The survey consists of rating 75 
candidates for political office on a scale of I to 5. 
These data have been punched onto 60 cardS/ each 
containing a contiguous stream of 75 digits. Your task 
is to produce a table giving the mean rating for each 
candidate/ along with the standard deviationi skewness* 
and kurtosis of the ratings. 



This problem can* of course* be solved without formatted input by 
defining a string* and using or d< ch >-ord( ' 0' ) to extract digits. 
However* this is hardly the point of the problem* and* in fact* 
detracts from the true object of the exercise. The psych student 
is really not interested in the use of "ord" or strings at this 
pointi he is interested in statistics. 



Example 2: 



Your Ph.D. Advisor has been teaching 



an 



undergrad course* and has compiled a card deck with the 
following information on it: Columns 1-9 contain a 
student's social security number; columns 11 to 70 
contain 20 3-digit numbers* each of which represents a 
score on a pop quiz (ranging from to 100). Your task 
is to print out the mean and standard deviation of each 
quiz* a correlation matrix of all quizzes* and a 



Again* it is possible to use •ord" to extract the three-digit 
numbers* but it is even less pleasant than before* and detracts 
even further from the point of the exercise. 

At this point, someone will object that there is no need to punch 
the data as a contiguous stream of numbers* and I agree. 
However* I will note that most psych surveys I have seen try to 
put as much data on a single card as possible. (Note that ue 
could not put all the data on one card i f we put blanks between 
numbers.) Besides saving keypunching time ond storage space 
(both of which are the equivalent of money!)* the people doing 
the surveys are interested in the resultant statistics* and 
couldn't care less about nicely-spaced input. In fact* I have 
even been told to keypunch real numbers as a contiguous stream in 
order to avoid "wasting time typing spaces!" 

Now, for a two-part example where formatted input is a near- 
necessity. This is a business problem* but I feel justified in 
giving it as an example -- Ulrth* in the Pascal report* says he 
put records and files into Pascal in order to "...make it 
possible to solve commercial type problems with Pascal* or at 
least employ it successfully to demonstrate such problems in a 
programming course." 



Example 3: The owner of a local jeans store has hired 

you* ace programmer* to do his inventory control and 
market research, i 



Part l! ' 
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Eoch day* you are given a deck of punched cards giving 
the day's sales total* one card per transaction. Each 



Your task is to take 5 days of purchases/ and produce a 
chart for each color/ style/ and material that shows 
the sales distribution by size. What conclusions can 
you draw fron your results? 






card looks like this; 



Columns 1-7 

Columns 9-10 

Columns 12-13 

Columns 15-19 



Serial number of jeans 
Waist size (range 26. .54) 
Length (range 26. 38) 
Quant i t y sold 



You nay assume that transaction records have been 
sorted by serial number; thus all purchases of #5050217 
will cone before all purchases of #7070217. Your task 
is to print out a chart for each serial number giving a 
sales record for that day. 



So far/ so good. Ho formatted input has been needed 
accomplish the first half of the example. Kow/ the clincher: 



Part II: 



to 



of data representation. Other examples include: 

l> Indiana license plates* whose first letter and digit 
serve as an index to an alphabetical list of county names. 

2) Illinois driver's license numbers/ which contain year of 
birth/ county of residencei and oodles of other information to 
help prevent forgery of the license* all packed into 11 digits. 

In all these cases/ repunching the data to separate the fields is 
clearly out of the question. These examples point out the need/ 
or at least the great desirability/ of having formatted input. 

Although I will agree that it is very easy for an installation to 
write its own formatted input routines as standard functions* 
this brings up the problem of transportability. It seems clear 
that the feature is useful enough to be "built-in" by many Pascal 
users. However/ these site-specific intrinsics will not 
transport easily from installation to installation. This iS/ in 
fact/ one of the failings of BASIC; people provided their own 
functions and "extensions" to do things that they needed (and 
BASIC didn't have). Now/ one would be hard-pressed to find two 
places where all the "extensions" agree. 



m 
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As we all know* the serial number on your pair of jeans 

is not arbitrary; the 5050217 signifies regular blue 

denim; the 7070217 signifies be 1 1 -bottoms . In fact* 
the serial number is formatted as follows: 



First 3 digits style 

505*regular/ 707«bells/ 303=scutoffs 
Hext 2 digits color 

02=»blue / 03«gree n/ 4* brown 
Last 2 digits material 

17=denim*25=hopsack/36=doubleknit 



In conclusion/ it appears that formatted input can be useful in 
many cases/ and almost necessary in others. It seems 
appropriate/ then* that such a feature should be added at the 
base language level rather than having every Pascal installation 
re-invent its own formatted input wheel. 



(^Received 4/26/76*) 
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This example is hardly far-fetched; most identifying numbers on 
clothing contain this sort of packed information. The point is* 
however* that there are a lot of applications which use this sort 
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Overlays: A Proposal 



Usa^e Considerations* 



James F» Miner 

Social Science Research Facilities Center 

25 Bleslan Hall 

University of Minnesota 

Minneapolisy Minnesota 55455 



As Pascal ^ains wider availability and user it shows itself to 
he a versatile and practical tool for serious production work* 
However? iSiven the recency of implementations ? it is understandable 
that a number of implementation features commonly employed in 
production work are not yet available* For some programming 
projects^ the ability to reduce the amount of storage reauired for a 
prd^aram's object code is of fundamental importance* Even if a 
proi^ram is proven to be corrects it may not fit on a aiven machine or 
it may suffer from poor performance due to operatinsi system 
restrictions* Both of these conditions occur in practice? and a 
number of technioues for avoiding them are widely used* The use of 
overlays is one such technioue* An implementation extension for 
Pascal is hereby proposed to provide this capability* 

The sloals of this effort are numerous? including effectiveness 
of the overlay mechanism in providing space reductions? simplicity of 
notation and understanding for the user? security from unintended 
ill-defined results? and efficiency of both compilation and ej<ecution 
mechanisms* In addition the scheme should be impiementable in a wide 
variety of environments* 



Pascal? with it s block structure? provides an excellent 
opportunity for the implementation of a secure? simple? and 
relatively transparent overlaying scheme* Procedures (and functions) 
often delimit major sections of the program which will be executed 
either inf reauently ? or which have (nearly) disjoint callind 
seauences? or both* Thus the overlay scheme? which reauires division 
of 3 prosfram into overlays? should take advantage of the existing 
division into procedures* This should be done in such a way that the 
effects of the overlayinsi are directly visible to the programmer and 
can be easily controlled* In my opinion? this can best be 
accomplished by the indication of overlay structurinsi at the source 
level* It is at this level that the programmer interacts with and 
understands the proaram. 

Let us assume that the proarammer may specify any procedure (or 
function) to be an overlay with a prefix symbol such as OVERLAY 
before the procedure heading* The prefix has the advantage of beinsi 
short and easy to use? but as visible as the procedure heading 
itself* The extent of the overlay is defined by the procedure body? 
so confusion is minimised* And finally? the compiler is informed 
immediately when it is about to process an overlay — the 
si!3nif icance of which depending upon the implementation* 

What meaning should the programmer attach to the OVERLAY 
prefix? The best answer should be 'no effect"? in terms of the 
correctness of his proi^ram or the restrictions placed upon him by the 
implementation* The programmer must be advised that the invocation 
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of an overlay will be more expensive than the invokation of 3 normal 
procedurer but the decision of how to avoid excessive overhead should 
be left to the usert 

Some implementation restrictions may be reasonablef such as 
aslainst passing overlays as parameters <i»e»r formal overlays) y or 
passing procedures or functions as parameters to overlays* A 
complete implementation would allow both of these cases? but they 
miaht be difficult to implement* and both can be readily detected 
(and thus restricted) at compile time* Disallowing recursive overlay 
calls is an entirely different situation because compile time checks 
are ineffective* and run time tests are to be avoided if possible. In 
addition* the normal scope rules for calling should not be 
constrained for overlays* functions as well as procedures should be 
overlay-able* and by all means* parameters and non-local references 
should be allowed* These latter three capabilities are desirable to 
maintain the basic similarity between normal and overlayed 
procedures * 

Finally* it is always possible for an implementation to simply 
ignore the OVERLAY prefix (Just as PACKED misht be islnored) either 
entirely or only after a aiven static overlay nestind depth limit has 
been reached* 



(1) Overlays are classified into levels* where only one overlay 
at a sliven level can be in core at one time* That is* overlays of 
the same level are loaded over each other* (Depending on the scheme* 
overlays at different levels may or may not overlap in core*) The 
lowest level overlay constitutes a main overlay which is always in 
core* which first receives control when the program is executed* and 
which initially causes other overlays to be loaded* The run time 
system (RTS) usually is contained in the main overlay. 

(2) In calls between overlays a load operation may be necessary 
so such calls either are trapped* or are made explicitly by the user* 
to a routine in the RTS which determines whether the called overlay 
is in core* and if not* causes it to be loaded and executed* 

(3) By Placing strategic constraints on calling seauences these 
schemes ensure that a routine to be returned to is in core* Thus the 
return can be performed exactly as though the program were not 
overlayed at all* The constraints necessary for this include 
prohibition of calls to overlays of the same or lower level which 
would cause overlay loading (thus possibly destroying the calling 
routine)* Because the main overlay is always in core* calls to its 
routines are allowed (but may cause undefined results if overlay 
loading occurs* and a return is subsequently attempted)* 
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Implementation Considerations* 

It is instructive to examine the common characteristics of 
overlay mechanisms used with Fortran* Of those with which I am 
familiar* three notable aspects aret 



The constraints placed uPon callin!^ seauences in the Fortran 
schemes may be "reasonable" aiven the kind of lan<suade involved* but 
certainly represent weaknesses of security since compile time checks 
cannot prevent undefined results and run time checks are often not 
made* 



CD 



The proposed Pascal overlay facility has the fallowing fGBtuvesl 

(1) The lev€^l of each overla*:^ is determined et compile time 
from the static nesting of the source* These levels are analoiSous 
but not equivalent to block nesting levels* The compiler assigns a 
uniQue identification to each overlayr in the form of a m-tuple or 
vector of ordinals » where m is the maKimum number of overlay levels 
in addition to the main level allowed by the implementation? and 
where the ordinal zero is reserved as a null marker* The nestinsi of 
the overlays is represented as follows! 

(a) The main overlay is represented by an all-zero (null) 

vector* 

<b) Overlays at the first level (after the Global overlay) are 

identified by uniaue non-zero ordinals in the first element of 

their vectors* Remainin*^ elements are zero* 

(c) In sJeneralf overlays at the n-th level are represented by 

vectors with elements one through n non-zerof and n+1 throudh m 

zero* In addition? to represent the static nestind? all level n 

overlavjs which have the same encomP3ssin<3 overlays are assigned 

vectors differing only in the n-th elements* 

(2) The configuration of overlays which are core resident at 
any point in time is represented by the Overlay Display Vector (ODM)y 
the value of which is an m-tuple as defined in (1)* The ODU is 
maintained by the run time systc^mr and is modified only when overlays 
are loaded* The followinsi rules are observed by the overlay 
mechanism t 

(a) Before any block in an overlay at level n can be invoked? 
the ODV must eaual the overlay's vector in at least the first n 



elements* If this requires the loading of overlays? then the 
value of the ODM prior to the call must be saved on the stack* 
<b) If before returnirt*^ from a call the non-zero elements of 
the stacked ODU value are e«ual to the cor resPondin.d elements of 
the ODU? then no loadinsJ is required to complete the return* 
(c) If loading is required to complete the return? then the 
i-th throusih the n-th level overlays indicated by the stacked 
ODU value must be loaded? where i is the lowest position of the 
stacked ODU value not eoual to the corresponding position of the 
ODU? and where n is the hisihest non-zero position in the stacked 
ODU value* 

(3) Assumin:^ suitable restrictions on procedure and function 
parameters (below)? the rules in (2) :3uararitee the foliowin<3 
conditions^ 

(o) Encompassing blocks are Guaranteed to be in core* Thus 
calls to and returns from encompassing blocks? and doto's which 
exit to encompassing blocks need not be trapped* 

(b) Non-encomP3ssind (including local) blocks must be in core 

unless prefixed* Thus calls to and returns from these blocks 

must be trapped only if the called block bears the OUERLAY 

prefix* ■ 

'Suitable restrictions" are that a procedure or function cannot be 

passed to blocks "outside of" (non-local to) the overlay in which the 

parameter is declared* Thus? a block bearing the OUERLAY prefix may 

occur as an actual parameter only in calls to other blocks which are 

local to it* 

(4) Easing the restrictions on procedure and function 



3> 






GO 

m 



UD 
CD 



-a 

CD 



7 
parameters in (3> reauires that the block-parameter descriptor (which 
contains the parameter's entry point and static link) he augmented by -o 

GO 

the tuple of the overlay which contains the actual pararTieter4 All C2 

r— 
calls to and returns from formal parameters must be trapped* -^^ 

m 

CO 

yhile the above points define the basic mechanism^ a number of fljlj 

-H 

problems may occur in specific implementations ♦ These will usually Pn 

po 

result from attempts to use existing loader or operatin*^ system =«= 

v-n 

software or conventions* A simple example is where the loader may 
not Provide information to the run time system to establish the ^vbb 
in core for heap and stack* The run time system should be provided 
with the space reouired for the largest possible conf isluration of 
overlays* 

A more difficult problem may ^t-^^^v in the mapping of the ni 

-a 

proposed hierarchical overlay structure to the structure supported by m 

5d 
the loader or operatinsl system* The most serious mis-match will ^ 

probably be in the restrictions enforced at load time on the number ^_a 

OD 
*^ 

of entry points per overlay? or on the direction of calls between en 

overlay levels* In additions there may not be a "nice" mappinai 
between the proposed identification scheme and the existing 
conventions* 

It is beyond the scope of this paper to delve into particular 
implementations^ except to note that this scheme has been partially 
implemented for the CDC AOOO/Cyber 70 series* It is hoped that this 

proposal will stimulate discussion on the topic of overlaying* and -o 

that interested readers will forward comments or criticism to the rri 



author or editor* 

(*Received 1/^H^*) 



"•minor* problems in PASCAL" 



Timothy M. Boriham 



In this article I intend to diseuss some small but 
significant •problems' or possible areas for im- 
provement in PASCAL. Before I begin, I would like 
to include three sections i a disclaimer, an ommission, 
and a defense. 

DISGUIMERi First of all, I like PASCAL. If I 
didn't, * I wouldn't spend time wi'iting about it. I 
think that it's easily one of the best languages 
around. I greatly admire the logical clarity and 
'austerity' of the language, the way program text 
tends to clearly show the progress of the actual 
execution, and the fact that the language tends to 
encourage good programming practices (compared to 
some languages (for example, FORTRAN or PL/1) which 
tend to do just the opposite.) Bxt I don't think 
that the language is perfect; therefore it's 
worthwhile to try to find areas that might be impr- 
oved. 

OMMISSIONi I will not discuss in this article two 
areas that are frequently said to be major deficiens:^ 
ies of PASCALr the general read-write procedures 
(which are difficult to use, especially in an 
interactive environment) and the definition and man- 
ipulation of common business-type files (which is 
less clear in PASCAL than in some other languages). 
I. will -also not discuss some problems that I do 
not think are specifically the fault of the lang- 
uage itself; for example, the unpleasantness and 
unhandyness to the user of most present PASCAL 
implimenta tions . 

DEFENSES to the charge that I'm being picky about 
small and unimportant elements of the language~I 
don't think that they are so unimportant. Biese 
elements are some of the most frequently used in 
the language and often make up a large part of 
the program. Also, several references have in- 
dicated that it is 'minor' inconsistancies like 
these that cause a large part of the difficulty 
in learning a language and problems with such 
elements account for a very sizable proportion 
of the compilation errors in programs. In any 



case, I don't think simply classifing awkward 
elements as small and unimportant is any reason 
not to try to improve them. 

Ihe main portion of this article will note 
specific PASCAL elements that I feel are problems, 
the reasons for this, and some possible improvements. 

1. identifiers— It is commonly acknowledged 
that identifiers should be chosen so that they have 
mnemonic significance to the programmer. Well chosen 
identifiers provide a form of self -documentation 
within the program itself. The most common ob- 
stacle preventing mnemonicly significant ident- 
ifiers is the limitation upon identifier length. 
PASCAL as defined has no specified maximum limit 
on identifier length. However, one of the goals 
of PASCAL(and presumably of programmers who use 
it) is to have a standard language "in order to 
facilitate the interchange of programs". For this, 
programs must distinguish identifiers within the 
first eight oharacters as required by Standard PASCAL. 
This is clearly a harsh restriction. FORTRAN is 
well known for encouraging incomprehensible vari- 
able names, and Standard FORTRAN permits six 
characters, while many present compilers permit 
seven, eight or even ten characters. In this area, 
PASCAL is only minimally better than Standard 
FORTRAN and equal or even worse than many present 
day FORTRAN compilers. 

A further problem with identifiers in PASCAL 
is the lack of a break character. This commonly 
results in identifiers which consist of several 
words run together, with resulting loss of clar- 
ity. The recommendation of a specific break 
character presents difficulties. The use of the 
hyphen(as in COBOL) maintains similarity to normal 
language usage, but requires additional restric- 
tions on the spacing of expressions to distinguish 
the use of the same symbol for subtraction (though 
these restrictions are not unfamilar, since they 
are the same as those normally used in writing 
and typesetting). The use of a seperate character 

for breaks (like the underscore in PL/1) imposes 
no such additional restrictions , but requires the 
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addition of another element to the character set* 
The use of the space character as a break char- 
acter(as in AUsOL) is unpleasant in several res- 
pects s it introduces unfortunate complexities 
into the compiler? it provides serious potential : 
for misuse (it is easy to make the same identifier 
look very different); and(though this may be just 
an oversight)^ the space character is not included 
in the basic symbols of Standard PASCAL. Whatever 
character is chosen, the availability of a seper- 
a tor character clearly enhances the readability 
of programs, 

2« the subrange syjnbol(,,) — the use of this 
sjrmbol as an abbreviated form of listing a subrange 
of a type is wery unfortunate in that it is simil- 
ar to, but not quite the same as the ellipsis (••♦) 
commonly used in the English languang and in 
mathematical notation. Items such as this should 
be either exactly the same, or sufficently diff- 
erent to prevent confusion i the worst case is to 
be •almost' the same. In at least one published 
case, an author (or possibly, his typesetter) 
unconsciously used three periods instead of two 
throughout his entire program, and was subsequently 
criticized for it. I consider the main error not 
to be that of this user, but of the language, which 
positively encourages this type of user error. I 
cannot think that the saving of a single character 
in writing the program is worth this confusion. 
(a similar example in PL/Ii miany numeri(£al formats 
are the same as those in FORTRAN-except for the 
use of a comma rather than a period. This has 
caused vast — and completely unnecessary— anguish 
to FORTRAN programmers attempting to work in PL/1). 

3« the assignment symbol(:=:) — the programmers 
operation of assignment is very different from the 
mathematicians assertion of equality and the lang- 
uage should clearly distinguish the two. Anyone 
who has ever tried to explain the statement 
X = X + 1 to a student learning BASIC knows thisi 
**you sea, sa means equals only in IF statements, 
otherwise, - doesn't mean equals, it means,..". 
Ihe use of a symbol other than the equals sign 
for assignment(unlike BASIC and PL/1) is good, 



but the symbol chosen(i=) perpetuates the con- 
fusion by containing within it an echo of the 
equality symbol. A better symbol might be the .. 
left arrow (<-^) as used in APL; which does not 
have such confusion. Also, the left arrow more 
clearly reflects the action of the program during 
execution; it is, as has been said, "almost 
onomatopetic". In addition, this symbol is easily 
recognized by APL users (the := may be readily 
recognizable by ALCiOL users, but there are more 
users of APL than ALGrOL, and their lead is grow- 
ing). I recognize that ^his symbol is not avail- 
able on all I-O devices, but it is on the majority 
of them, and on others it could be replaced by 
a two character synonyrrif similar to the way comment 
symbols are handled, (perhaps the less than and 
hyphen symbols iKr*) would be good). 

In addition, the left arrow symbol saves one 
character, a minor advantage; more importantly, 
it provides higher relialibility. In the := 
sjmibol, there is a chance of skipping one of the 
characters in the symbol and thus converting it 
into another valid symbol. (lAickily, in PASCAL, 
unlike some languages, such an accidentally created 
construct would always be invalid at its present 
place in the program, and thus should generate an 
error message), 

4. ascending directional symbol of the for 
clause (to)— This symbol itself, when encountered 
in a program, gives no specific indication of dir- 
ection to the reader. Ihe user is able to discern 
that the value changes occur in an ascending seq- 
uence only through comparison to the alternative 
symbol, downto which clearly indicates a descending 
s equenc ejor through a study of the language manual), 
A better symbol, which would make the direction of 
change readily apparent to the reader; and also be 
more congruent with the alternative symbol downto , 
would be the symbol upto . The additional clarity 
to the readerwould, I feel, be easily worth the 
minimal cost of two extra characters in the symbol. 

5. A final controversial issue is that of the 
c ommento § true tur e , 

There are three raiain types of comments that are 
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comraonly included within a programs prologue 
comments — this is general information about ' 
"Uie program (author, date-written^ size, etc.)* 
block sumraary-- these comments emphasize the function 
and purpose or indicate the logical unity of a 
block of code? local information — this spotlights 
critical steps or meanings for a small section of 
code* Iftiese three types of comments are clearly 
different in both their nature and their location 
within the program. The comment structure should 
clearly distinguish them. Unfortunately, the com-s 
ment scheme of PASCAL does not do soi all must be 
written using the same (* and '^) brackets. This 
scheme, though flexible (in location) and versatile 
(regarding length of comments) lacks reliability i 
forgetting (or mispunching) the closing bracket 
turns the remainder of the program into comments « 

Prologue comments are normally located near 
the beginning of the program i they consist of a 
solid block of commentary, usually of a fairly 
standardized nature. The best structure for 
these is a dedicated block with a predefined, 
standard format, similar to that of the Ident- 
ification Division of COBOL. The fill-in-the« 
blanlc nature of such a structure is especially 
important in view of its tendancy to encourage 
the automatic inclusion of such a block. As an 
example of this, both COBOL and FORTRAN provide 
a mechanism for including such information within 
the program J COBOL in a predefined format, and 
FORTRAN through the use of the general comment sch- 
eme; yet many more COBOL programs include this 
information than FORTRAN programs. 

Block summary comments are usually located at 
at the beginning and/or end of various blocks of 
the program. They normally consist of several full 
lines of comments. The present PASCAL comment 
structure seems to work well here, though the 
scheme presented below for local information might 
prove better. 

Local information comments are usually made 
up of a line or two before a statement or the last 
half of the lines that the statement is written on. 
A possible iinprovement over tlie present PASCAL 



comment structure might be the use of a symbol 
like { or (* to indicate that the remainder of 
the present line is to be considered commentary. 
This scheme uses the end of the line as an implicit 
closing bracket to the comment. This improves the 
reliability of the comment structure (by eliminating 
the problem of the missing ending bracket) and 
accommodates both of the styles of load information 
comments mentioned. The only cost to the lang- 
ixage user is the neccassity of repeating the 
beginning symbol if the comment is three or more 
lines in length. Local information comments 
normally are not, and should not be this long. 

Overall, it seems to me that PASCAL has elim^ 
inated most of the major faults of many other lang- 
uages! but, unfortunately, has also eliminated some 
of the (often minor) elements of these languages 
that worked well. This is easy to do, a languages 
vices are much more noticed than its virtues, I 
feel that the elements that I have discussed in 
this article can be changed without altering the 
main philisophy of PASCAL and, probably, without 
much difficulty in modifing the compilers, 

I hope that this article will stimulate dis- 
cussion on these issues; and would gladly welcome 
comments on it; either in private communications 
to me (Tim Bonham, D605/I63O S, 6th. St., Minnea- 
polis, MN 5^^) or in items published in the 
PUG newsletter. 



(^Received 7/15/76*) 
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_7- 
Dynamic Array Parameters 

p .iQb, 1 ,p 

by Ch. Jacobi , E.T.H., Zurich ^•''- dynamic array types. 

-o 
(*What follows are pages 6-10 of a proposed description of dynamic array parameters ^ .1»J9.- 1.13 g 

which is probably of interest to many PUG members. Pages 1-5 were not sent; lew. high <--> 



they were in German.*) 
Corrections to PASCAL - User J/.anual and Report 



z .'iVd replacs 1.20 - 1 /dZ _^ 

•;C22enciing on which version is implemented, m 

rr.e ::art with packed should be omitted.) ^ 



<formal parameter section> ::= <extended parameter groijp> 



m 



P./*:,l.12andl.13 ^*.^-, ^ , 

' ^y .. _ » .. ^* var <extended parameter group> I 

f unct ion <parameter grouD> j 

r. -1'^ \ A procedure <identifier> 1 .<ident if ier>} 

Ic is also possible to write a procedure without fixing the v-«s,4.««h«^ « *. „ ^ .. ^^ m ». - c - ^ r ^-^ i.jr>- ^i 

. ^ - . ^ . ^ ^ ^ X. T ^i- ^ , <extencled parameter group> ::= <identifier> I , <ident if ler >} 

bounds of the index type of array parameter. In the formal <tyoe identifier> I 

parameter section the name is not followed by its type." but by <identifier> {. <ident if ier >} : <dynamic array type> 

an array declaration which has a scalar index type. The bounds 

of the index types then are taken for each parameter from the <dynamic array type> ::« array [ <scalar type identifier> 

corresponding actual parameter. These array parameters are \^ <scalar type identifier>} ] of <type identifier> I 

called dynamic array. Packed array [ <scalar type identifier> 

Program 11.3 shows the case of a dynamic array parameter. The {, <scalar type identifier >} ] of <type identifier> 

standard functions low and high deliver the index bounds . 



p .fa3 bottom 

4, A dynamic elttq.'^ must not appear as an actual parameter if 



<scalar type identifier> ::» <identifier> 



oo 



the corresponding formal parameter is not a dynamic array. ~^ 

(Depending on which version is implemented) m 

Neither must they have dynamic array parameter , gS 

rn 

(Depending on which version is implemented) ^. 

b. Dynamic arrays will be packed only in one dimension. A ,_, 

dynamic array declaration I^ 

packed array [ scalar 1 ... . .scalarN] q/ type-id cn 

accepts as actual parameter , beside an equally declared 
dynamic array, also an array declared as • 

array[ scalar 1 ,.. . ] of packed array [ scalarN] of ... 

P.^7, 1.31 

3. The standard procedures pack and unpack must not have 
d/namic arrays as actual parameter. 

p .103, 19 ^ ^ 

'end parameters*. — > '.parameters and index bounds of dynamic 
arrays . * 

p ;107 bottom • 

low (x ) x is a dynamic array variable,' the result is the ^ 

lower bound of the index cf the array, ^^ 

high(x) X is a dynamic array variable, the result is the [jj 

upper bound of the index cf the array. 



p .117 replace the diagram parameter list 
parameter list 




FUNCTIOrI> -y ^dentif ier| j{7V[type identifier} - 



rPRQC£DURE> 




dynamic array type 



g_^J<£D)?<ARRAV>(n dtype identifierU fi)H(OF)-H itype identifier 



-O 



p .121 bottom 

40U: Dynamic arrays must have a scalar index type 
401: Packing and unpacking of dynamic arrays are not 

implemented 
402: Dynamic array expected 
403: Type identifier or dynamic array type expected 

(Depending on which version is implemented) 

404: Formal procedure must not have dynamic array parameter 

p .126 alphabetical 
dynamic array 1 1 .A 

p .131 after last line of a. 1.4. 

In this case the arrays must not be dynamic. 



p .1t?a replace 1 .3p - 1 .39 

(Cependin;: on which version is implemented, 

tne part with pecked should be orritted.) 

<r'ar.T.aX parameter section> '■ '- = <extended parameter group> f 

var <extended parameter group> I 

fu ret ion <pcram5ter group> | 

prccedure <idsntifier> { , <ident if ier >} 

<extended parameter grauo> ::= <identifier> {, <ident if ier >} : 

<typa identifier> 1 

<identifier> { . <ident if ier>| : <dyna.T,ic array tyoe> 
<dynamic arrsiy type> ::= array [ <scalar type identifier > 

{ . <scalar type identifier>} ] of <type identifier> | 

packed array [ <scalar type identifier> 

{ . <scalar type identifier>} ] o_f <type identifier> 
<5calar type identifier> ::=» <identifier> 

p .15b. 1.-1 

The index type of a dynamic array type is substituted for 
every parameter by the subrange used as index in the 
corresponding actual parameter . 

p »1t>9 bctzom 

(Depending on which version is implemented) 

Packed dynamic arrays are only packed over their last 

dimension. An array of the form 

packed array [ sea larl -scalar2l Qf typeA 
must in the calling procedure be declared as 

array [scalar 1] of packed array [scalar23 of typeA. 

p . 1 b4 , 1 . 1 tJ 

lo* (x ) X is of dynamic array type, and the result is 
the lower bound of the index type of the 
corresponding actual parameter for x . 
X is of dynamic array type, and the result is 
the upper bound of the index type of the 
corresponding actual parameter for x . 

p .166 bottom 

d. Dynamic array types should only be used elementwise 
(Exceptions are procedure and function parameter) 



high(x ) 



p .169 alphabetical 
dynamic array 
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p'.152, 1,24 

The variable and the expression must not be dynamic arrays. 



(*Received 7/22/76*) 
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502 E. Healey #20? 
Champaign, IL 6l820 
5 November 1975 



Hello Andrew, 



Enclosed find the only information I have about the PDF 11/20 
version of PASCAL, From a report of a friend using the compiler, 
there may still be bugs in it, I will try to get you a name of 
someone to contact about distribution, progress, etc, 
Unfortuaately I do not work with that group or their machine and 
have no real channel to them, I may do some PASCAL work on the 
machine, though, just to see how it is. 

I do have some rather promising information in another area. 
Chances are you probably know about it already, but in case you 
don'ti Wirth has come out with a subset of PASCAL (called PASCAL-S) 
and has written: 

N, Wirth PASCAL ~S x A Subset and its Implementation 
Eidgenossische Technische Hochschule Zurich 
Institut fur Informatik — Report ,# 12 

I believe the date on it is June 1975 — hut don't quote me! 
I got a copy of the manual from Dr. M.D, Mickunas, who received 
it from Dr. Jurg Nievergelt. Dr. Nievergelt was on sabbatical 
in Switzerland and sent it back from there, (Both teach here 
at the University of Illinois), I'm enclosing 2 pages detailing 
the major differences between the subset and full PASCAL. 

If you want a copy of the whole schmeer, I'll be glad to eet one 
and mail it to you. (Again, if you don't already have one J, 

One noteworthy feature of the manual is its chapter 7t which 
contains a version of the compiler and interpreter, written in 
full PASCAL, The compiler produces code for a hypothetical stack 
machine, which the interpreter (naturally) interprets. 

The following is pure speculation (especially pending some funding) 
butt Rick Simkin and I are thinking of translating it for the 36O, 
We were originally thinking of rewriting it into PL/l but neither 
of us is terribly keen on it. (Even though it would be the 
easiest, I guess I for one just want to avoid PL/I wherever -oossible) 
What we may well do is have me write the. compiler in SPITBOL (for 
speed ;0f character manipulation) and have Rick write the 
interpreter in FORTRAN (for raw speed). I will definitely get 
back to you on this if we can con anyone into giving us funds to 
do it, , 



That is basically all the info I have for right now. 

As for your request for a new name for the group, how about 

Association of Pascal Programmers, Ltd, (AFPL) 

Sorry, that's the best I could come up with at 11 OO PM. 

At any rate, I think we should try to avoid "PASCAL X^^'terest Group" 

unless we really want to shock and/or offend. The more I 

think about it, the better it soiinds. . .must be the late hour. 

Sorry also about the typing errors; I have never really fully 
believed in proofreading. 
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PS — You may want to include phone numbers on future mailing 
lists J some developments or exchanges are not handled best by 
the US Postal Service, Also, most Universities have WATS line? 
for "University business.** 

PPS— -My office phone t (217) 333-1719? the office is shared by 
a lot of people so don't be surprised if you hear a female voice 
answwring. ,, 
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PASCAL NEWSLETTER #5 SEPTEMBER, 1976 PAGE 25 

Q .7^ insert new page 

{ program 11.3 
extend program 11,2 J 

program fninfDax4(input , output ) ; 

const n = 20; m= 15; 

t y p e listn = array L 1..n] of integer: 
listm == array [ 1..m] of integer: 
var a : listn : b : >listm ; 
i ,min .max : integer: 

procecure minmax (var g: array [ integer] of integer: 

\JBr j ,k : integer); 
var i.l^h,u,v:int8ger; 
begin 1 : = low (g ) ; h : =: high (g ) ; 
J := g[l] : k := j : i :« 1 + 1; 
w h i 1 g i <h do 

begin u' : = g [ i] : v/ := g[ i + lj : 
if u > V then 
begin if u >k then k : = u ; 

i-f ^ < j t hen j : = V 
end els e 
begin if v >k then k := v ; 

if u < j then j : = u 
end ; 

i : = i +2 
end ; 
if 1 =h then 

if g[h] >k then k := g[hj 
else if g[h] <j t hen j :« g[h] ; 
end ; {minmax'J 

begin 

for i • == 1 to n do 

becjin read (a[ i] ): write(a[i] :3) end : 

writeln ; 

minmax (a .inin ,max ) ; 

wr iteln (min ,max ,max -min ) : writeln; 

for i := 1' to m do 

begin read(b[i] ); writB(b[iJ :3) end ; 

wr iteln ; 

minmax (b .min ,max ) ; 

writeln (min .max .max-min) 
end . ■ • . , 

^1 -3 4 7 a 54 23 ~5 3 "p 9 9 ~6 45 79 3 1 1 5 
^b 79 6d 

45 43 3 b 1 34 ^a 1 4 34 3 a -1 3 ^2 

-a ^45 . 53 
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p *yd Insert new page 

{ program 11,3 
extend program 11.2 ^ 

pr GGram rninrr.ax 4(input , output ) : 

co nst n=2Q;m=15; 

z V p e listn = array [ 1.«n] of integer: 
1 i s t m = array [ 1 > > m 1 of integer; 
var a: listn: b: ,listm; 
i ..7»in .max : integer: 

"' procecure minmax ( var g: array [ integer] of integer: 

var j ,k : integer ) : 
var i.l.h.u.v: integer: 
begin 1 := low(g): h :- high(g): 
j := g[l] : k := j : i := 1 + 1 : 
whi la i <h do 

begin u* :- g [ i] : v := g[i + 1J : 
if u >v t hen 
begin if u >k t hen k : = u : 

iX V < j t hen j : = v 
end else 
begin if v >k then k : = v : 

if u < j then j : = u 
end : 

i : « i -f 2 
end : 
if i =h then 

if g[h]>k then k := g[hj 
else if g[h] <j then j :» g[h] : 
end :-fminmax^ 

begin 

for i • = 1 to n do q 

begin read(a[i] ): write(a[i] :3) end : 

writeln : 

minmax (a .hiiri #^a>^ ) • 

wr iteln (min ,max .maxHmin ) : writeln: 

for i :== 1'tp m do 

begin read(b[i] ): write(b[i] :3 ) end : 
writeln ; 

minmax (b ,min ,max ) : 
writeln(min^max.max--min) 
end . 

-1 -3 4 7 a 54 23 -3 3 9 9 9 -6 45 79 3 t 1 5 
-6 79 Bd 

45 43 3 b 1 34 ~B 1 4 34 3 B ^1 3 ^2 
-c 45 ,53 



502 E. Healey #20? 
Champaign, IL 6l820 
5 November 1975 



Hello Andrew, 



Enclosed find the only information I have about the PDP 11/20 
version of PASCAL, From a report of a friend using the compiler, 
there may still be bugs in it, I will try to get you a name of 
someone to contact about distribution, progress, etc. 
Unfortuaately I do not work with that group or their machine and 
have no real channel to them, I may do some PASCAL work on the 
machine, though, just to see how it is, 

I do have some rather promising information in another area. 
Chances are you probably know about it already, but in case you 
don't I Wirth has come out with a subset of PASCAL (called PASCAL-S) 
and has written i 

N, Wirth PASCAL -S i A Subset and its Implementation 
Eidgenossische Technische Hochschule Zurich 
Institut fur Informatik — Report #12 

I believe the date on it is June 1975— but don't quote me! 
I got a copy of the manual from Dr. M,D, Mickunas, who received 
it from Dr. Jurg Nievergelt, Dr. Nievergelt was on sabbatical 
in Switzerland and sent it back from there, (Both teach here 
at the University of Illinois). I'm enclosing 2 pages detailing 
the major differences between the subset and full PASCAL. 

If you want a copy of the whole schmeer, I'll be glad to eet one 
and mail it to you. (Again, if you don't already have one J. 



That is basically all the info I have for right now. 

As for your request for a new name for the group, how about 

Association of Pascal Programmers, Ltd. (APPL) 

Sorry, that's the best I could come up with at 11 i 30 PM, 

At any rate, I think we should try to avoid "PASCAL X^terest Group" 

unless we really want to shock and/or offend. The more I 

think about it, the better it sounds, , .must be the late hour. 

Sorry also about the typing errors j I have never really fully 
believed in proofreading. 
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PS — You may want to include phone numbers on future mailing 
lists J some developments or exchanges are not handled best by 
the US Postal Service, Also, most" Universities have WATS line? 
for "University business." 

PPS— My office phone t (217) 333-1719 1 the office is shared by 
a lot of people so don't be surprised if you hear a female voic< 
answering.,. 
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One noteworthy feature of the manual is its chapter 7t which 
contains a version of the compiler and interpreter, written in 
full PASCAL. The compiler produces code for a hypothetical stack 
machine, which the interpreter (naturally) interprets. 

The following is pure speculation (especially pending some funding) 
butt Rick Simkin and I are thinking of translating it for the 36O. 
We were originally thinking of rewriting it into PL/l but neither 
of us is terribly keen on it. (Even though it would be the 
easiest, I guess I for one just want to avoid PL/I wherever possible) 
What we may well do is have me write the compiler in SPITBOL (for 
speed ;0f character manipulation) and have Rick write the 
interpreter in FORTRAN (for raw speed), I will definitely get 
back to you on this if we can con anyone into giving us funds to 
do it. 



CD 



CT) 



- 2 



EIDGENOSSISCHE 
TECHNISCHE HOCHSCHULE ZORICH 



Institut fur Informatik 



Clausiusstrasse 55 

CH - 8006 Zurich 

^ 01 / 32 62 1 1 



Mr. Andrew B. Mickel 
University of Minnesota 
Computer Center 
227 Experimental Eng, Bldg. 



However, vjith the former notation one pass , 

so'ns because the tyoe of thei variable is not known at the moment th 
(possibly structured) value is rec3d. Also, I guess that at the time de- 
clarations are written initial values may still be unknown. So a strong 
MINNEAPOLIS Minnesota 55455 separation between declaration ana initialisation is perhaps legitimate. 



compilation can become cumber- 
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November 22, 1975 



Dear Andy, 

I have some news for you: 

1) One of our students is actually implementing dynamic array para - 
meters as part of his work for his master degree. The PASCAL syntax 
will presumably be (change in PARAMETER LIST only): 




\ ne 



ex. procedurg p ( a : array [integerj of real); 



The additional standard functions LOW and HIGH deliver actual array 
bounds (in this example L0W{a,1)5f LOW{a) is ok. While LOW ( a , 2 ) results 
in a compile time error message because "a" was declared to be a 1 -di- 
mensional array only. The second parameter must always be a constant. 

In 




2) Another student tries to implement a (type checking) value part as a 
semester job. If he succeeds I am willing to make it part of RELEASE 
2 too. However, I strongly doubt whether he will find a feasible so- 
lution and work it out in time. In any case he will not complete his 
work before February. 

By the way: I have no good arguments for the value part and against 
initialisation in the yar . part. Binding initialisations to types seems 
to be inappropriate because they are rather attributes to variables than 
to types. This is why I wculd prefer 



var 1 =o , J 



1 : integer ; c1 = (o,1), c2 = (1,o): complex 



3) The idea of implementing a constructor function has been postponed, 

V^e have (for the time being) nobody who could do it. Our new assistant 
will only join us in January and not in December as I wrote you. 

4) Hope^fully DISPOSE will not die! I will talk to Wirth about it. In my 
opinion NEW without an "inverse" is useless. 

We were pleased to hear that the first PASCAL User's group meeting was 
(spontaneously!) held at ACM '75. (Two weeks ago a so called PASCAL-Day 
has been organised by the Swiss chapter of the ACM. About 50 people 
attended which, following the chairman, was quite a success). 

Please inform us when you have news concerning duties of the Newsletter 
editorship. 

Sincerely, 
I 

Urs Ammann 
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(Short, informal correspondence) 



var i,j :inteqer -0; c1,c2 rcomplex = (o,1). 



OPEN FORUM FOR MEMBERS 
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November 25, 1975 



Professor Niklaus Wirth 
E.T.H./Ciausiusstrasse 55 
CH~8006 Zurich 
SWITZERLAND 

Dear Niklaus: 

I am writing to you to ask some questions coacemiag the language Pascal. 
As you may know we at Minnesota have been corresponding with Urs frequently 
on the subject of implementation details for the CDC 6000 Pascal compiler. 
I am pleased to say that this interchange has been quite rewarding for us 
and hopefully beneficial to the compiler effort at Zurich. Because we 
included questions in our letters to Drs which concern the language 
Pascal, he suggested that we write to you, which we are doing now- 

I am sure your work now continues to move ahead in the areas of programming 
language design. It seems to me that when enough improvements or results 
of research work are made, then they may become manifest in a new language 
because of the undesirable consequences of changing a language which is 
heavily being used as a practical tool. You have stated that Pascal "will 
not be subjected to changes" with the appearance of the User Manual in a 
letter to me December 19, 1974. I am disillusioned to face changes in 
the language Pascal and extensions to the CDC implementation. 

The reason for the confusion and disillusionment on my part is that I must 
often explain to users why Pascal must not be changed ("preaching the 
gospel") and then be undercut by certain changes. There are some extensions 
to the CDC version which everyone says are worthwhile and which I tell 
people will be added "eventually" (e.g. a value initialization facility). 
While we seem to be making progress on the latter, let me enumerate 
instances of the former: 

1. Definite change to the language — the removal of DISPOSE as a 
standard procedure in the second edition of the User Manual . Why? 

2. We sent you a copy of our letter to Urs about the error trap 
label and the changes to the READ procedure for integers and reals. 

3. And what about other changes (such as extending READ and WRITE 
to act on files of any type)? 

Obviously you have received much pressure from users to make these changes. 
Do all CDC users have to suffer these changes? Could it be suggested that 
these are optional extensions for the people who want/need them. George 
Richmond distributes all of your updates to us in North America as 
"mandatory". Could a statement be issued to the effect that specific 
previous changes are optional? 



A Pascal User's Croup is being formed in North America. The first meeting 
of a group was informally held ac ACM '75 here in October. One very 
heartening aspect of the meeting was that many people who spoke expressed 
the same concern: "Hill there be a proliferation of non-compatible 
extensions in different implementations of Pascal?" At stake are portable 
Pascal programs which are written beyond standard Pascal. The statement 
was also made that "Pascal is our only viable hope to Deep-Six (bury) 
Fortran", and we cannot afford to blow our (perhaps last) chance to do 
that. For if we fail, we become another reason why Fortran should not 
be challenged, 

Aa important group of people in this regard are the maintainers and 
implementors of Pascal compilers. They must be both responsible and 
energe tie-hence the need for a User's Group. The Pascal Newsletter has 
been the only previous vehicle available; and even though George has done 
a good job, it must be published more regularly, and include articles 
discussing issues such as extensions in various implementations. 



Sincerely, 
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December 10, 1975 



Dear Andy, 

I thank you very much for your letter and appreciate your 
concern about the language Pascal. In fact I share it and I 
sympathise with your attitude against changes. But you really 
put me on the defensive, and I feel obliged to clarify a few 
points of possible misunderstanding. 

First of all I wish to distinguish clearly between l anguage and 
implementation . This is a very important distinction; the 
language is defined by the Report alone, and intentionally 
leaves many details unspecified that an implementation inherently 
must define one way or another. Secondly we must distinguish 
between change and extension . I have repeatedly stated that I 
wish to refrain from changes of existing features of the language. 
But obviously I cannot prohibit other people to implement 
extensions, nor even - alas - to introduce local changes. After 
all, the compiler is distributed in source form which facilitates 
the incorporation of changes. We ourselves have currently several 
students who implement extensions, but I don't know whether they 
will eve^ become part of our distributed CDC compiler. Even if 
they did, this would in no way imply that they become part of 
Standard Pascal. Actually, I am sure they would not, because 
we cannot afford changing (extending) all the published manuals 
and documentations. Hence, some current work on a data initiali- 
zation facility will at most become a part of the CDC 6000-3.4 
system, a facility, however, that does in no way modify any 
eiiisting feature. My attitude and intent are to be very tight^ 
with allowing extensions to go into our distributed and maintained 
compiler. 

You mention three issues in particular: 

1. The removal of DISPOSE. The trouble is that it had never 
really existed. Moreover, it has become increasingly clear 
that a truly satisfactory realization would be quite difficult 
and of an unwelcome complexity. It is quite possible to implement 
a non-checking version which, however, bears the danger of leaving 
"dangling references" hanging around. From the point of security. 
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I think it is an advantage, if Pascal centers follow our distributed 
updates, but we certainly cannot force anyone to do so. The nsxt 
update will be, as I am aware, considerable. But again, it incor- 
porates no language changes, merely improvements of the compiler 
which ultimately are in the interest of all users of Pascal. The 
new version will eliminate several restrictions which are some- 
times quite bothersome. Again, they are of course optional to 
those who don't wish to profit from our efforts. 
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I am very pleased to hear about the formation of a Pascal 
user group, and of course I share the hope that Pascal may 
contribute to overcame the Fortran age. But of course there 
are limits to the support of portability. Every installation 
will always provide some features that are convenient on its 
machine, but difficult and often counterproductive if imitated 
on other computers. I see no use in aiming for transferability 
of programs that use such local features, i.e. which don't 
adhere to Standard Pascgl. 



C.A.R. Hoare and N. Wirth, An axiomatic definition of the programming 
language Pascal, Acta Informatica ^, 335-355 (1973). 

N. Wirth, Systematic Programming , 

Prentice-Hall, Inc., Englewood Cliffs. N.J. 1973. 

K. Jensen and N. Wirth, Pascal - User Manual and Report . 

Lecture Notes in Computer Science, Vol. 18 (1974), and Springer 
Study Edition (1975), both Springer-Verlag. 
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Here at Zurich we would also welcome a Newsletter appearing 
more regularly. But at the same time I must confess our 
inability to run it, which doesn't mean that we shall not be 
happy to contribute and to support it. Please keep me informed 
about future developments. 



N. Wirth, Svstematisches Programmieren ( Taschenbuch ) 
Teubner-Verlag , Stuttgart, 1973. 

P. Brinch Hansen, Operating System Principles , 

Prentice-Hail, Inc., Englewood Cliffs, N.J. 1973. 



Sincerely yours, 

I 



l/iJJau/i [icn^ 



Niklaus Wirth 



A.N. Habermann, Critical comments or the programming language Pascal, 
Acta Informatica 2, 47-57 (1973). 

L' . Ar-^ann, The method of structured programming applied to the 

cevelopment of a compiler. International Computing Symposium 1973, 
A. G-Unther et al., Eds .» North-Holland (1974). 



cc: G. Richmond 



D. Lecarme and P. Desjardins, More comments on the programming language 
Pascal, Acta Informatica £, 231-243 (1975). 
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Literature about the Programming Language PASCAL 



Oct. 1975 



N. Wirth, An assessment of the programming language Pascal, 

IEEE Trans, on Software Engineering X, 2, 192-198 (1975), anc 
5IGPLAN Notices 10, 6. 23-3G (1975). 

L, An.T.anr, Die Entwicklurg eines Pasccl-Compilers nach der Methoce 
Ces £tru'< turier ter Programmiere'-s . EIH-Diss. 5456 (1975). 
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N. Wirth, The programming language Pascal and its design criteria. 
Paper presented at Conf. on "Software Engineering Techniques", 
(NATO Science Committee) Rome, Get. 1969, and published in 
•*High Level Languages**, Infotech State of the Art Report 7, 1972. 

- The programming language Pascal, Acta Informatica 1, 35-63 (1971). 

- The design of a Pascal compiler. 

Software - Practice and Experience JL, 309-333 (1971). 



r. 5^inc^ Hansen, The purpo5e_of Corcurrent Pascal, 
SIGFLA\' Notices IC, 6, 3G5-3C9 :'!975}. 

N . Wirth, Alqorithmen und Da tens truK turen , 
TeuDner-Verlag , Stuttgart (1975'. 

- Algorithms •» Datas true tures = Programs . 

Prentice-Hall, Inc., Englewooc Cliffs. N.J. 1975. 



•J. Welsh and C. Quinn, A Pascal compiler for ICL 1900 series computers. 
Software - Practice and Experience 2, 73-77 (1972). 

R. Schild, Implementation of the programming language PASCAL, 

Lecture Notes in Economics and Mathematical Systems, 75, (1972). 

G. Friesland, et al., A Pascal Compiler bootstrapped on a DEC-System 10, 
Lecture Notes in Computer Science 7, 101-113 (Springer-Veriac 1974), 
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'] UNIVERSITY OF MIlNNESOTA University Computer center 
- TWIN CITIES 227 Experimental Engineering Building 

Minneapolis, Wmnesota 55455 



December 29, 1975 



Prof. Niklaus Wirth 
Institut fiir Informatik 
E.T.H./Clausiusstrasse 55 
CH-8006 Zurich 
Switzerland 

Dear Niklaus^ 

Thank you very much for your nice letter which arrived Monday, December 
15. Also thanks for enclosing the updated bibliography, which is valu- 
able to have. I am grateful that you took the time to explain a lot 
of things. Shortly after I mailed my last letter (November 25) to you, 
we received a letter from Urs containing the retraction of most of 
UPDATIO. We were very happy to see that. 

I didn't mean to put you on the defensive when I wrote my letter. I 
really feel bad about that. Jty intention was to get some substantive 
infomnation which you have provided to my satisfaction. You are right: 
I as a local maintainer (and I am sure others like me) was confusing 
both the language with the implementation and also changes with 
extensions . After I got your letter I have to admit that I spent 
quite a bit of time going over all of our correspondence (including 
that with Urs) over the past year and noticing how many times I failed 
to make these distinctions. And when I wrote my letter of November 25, | 
I remember trying to decide (and wondering) under what categories to 
identify certain changes. Now when I reread that letter I also see 
that I failed to communicate several things properly. In several cases 
I misrepresented what I meant to say. 

Looking at your- letter now: "The language is defined by the Report 
alone which intentionally leaves many details unspecified that an 
implementation inherently must define in one way or another." Fine; 
I understood from having read the original Report (with the long intro- 
duction - before it was published in Acta Informatica ) and the "Axiomatic 
Definition" that leaving certain details unspecified is an advantage. 
Being somewhat partial to semantics over synta:<, I would hope chat the 
"Axiomartic Definition" helps to define the language, too. 

Now to consider "change." I agree with the notion that Pascal itself 
represents a major departure from the past (and past mistakes). And I 
personally do not mind change in and of itself if it is properly motivated. 
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Of course the environment for changing the language Pascal has itself 
changed over the last 5 years so that now it is difficult to effect change 
(more users, changes to existing documentation (as you stated), and 
portability considerations, to name several). What pops into my mind is 
that we have several Pascal Reports. The original (1970), the Revised 
(1972), and then two more (July and December 1973) that were small improve- 
ments on the way to the book: Pascal, User Manual and Report (revised, 
revised Report?) and now the second edition of P, UM & R which contains the 
change about DISPOSE. I guess if we only go by published (other than 
technical reports) versions there is only one Revised Report - the one in 
P, UM & R . I just want to show you that these minor details helped confuse 
me. So my last letter had only one valid gripe about changing the language 
Pascal - the elimination of DISPOSE in the second edition and your explanation 
is entirely satisfactory. But you didn't announce it officially, and I 
wanted to raise the question because I wasn't sure. 

I don't want to put Urs in the middle of this discussion but just to be 
sure that I tell you as much as I can on the issue of changing the language 
I want to add that it was Urs who said specifically: "By the way: would 
you please send letters concerning the language PASCAL to Wirth and not 
to me" in a letter to us October 29 in response to our criticism of UPDATIO 
in a letter to him (and copy to you) October 9. This implied that we had 
dealt with the language itself and not just extensions to the implementa- 
tion which I now know (thanks to your letter) to be the case. 

Concerning the change in the READ procedure for integers and reals and 
also looking at our October 9 letter, I quoted your letter of December 9, 
1974 about the User Manual describing Standard Pascal and Urs* November 28, 
1974 letter saying that the schema in the User Manual for reading from a 
textfile will be valid no longer if our suggested change for reading were 
adopted. Two points here: 1) the schema concerned must not be part of 
the User Manual describing Standard Pascal as this feature involves an 
implementation-defined definition, and 2) your indication that there 
will be a change to READ after all turns out to be exactly the same one 
we suggested and sent in a letter November 7, 1974 which produced the 
replies from you and Urs (see enclosure) . We rejected our own change in 
the light of those replies. - 

Continuing with your letter, I understand now that error trap labels are 

an extension to the CDC implementation. But in spite of what you said 

about extensions, I have an intuition that they are slightly contrary to 

the philosophy of Pascal, I apologize for putting down in my letter the 

reference to the extension of READ and WRITE to handle files of any type, 

and "other changes" referred fact to other e:<tensions . I was in the mood 

to question ever/thing at: that point. I did not at ail dislike the extension 

to READ and WRITE. Xdisu^rcv fi-xii-il- iSj^liy iIoc(/>»''^hfJ U 4ki ^r-^-U^i^l a^ ^yjri-, G* yay jJ^^/M-i/^^ 

I too think it is an advantage if Pascal centers follow your distributed cd 

updates. I hope that our deeds as well as talk support this. We have •"■"• 

maintained all along that working with you was far more productive than Usi 

going off on our own (as several installations have done) . We in fact 
(as stated in the letter of October 9) incorporated every update fully 
except UPDATIO. 
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Now I see that you aren't necessarily working on a new language at all, 
but possibly testing and implepenting new language features (extensions) 
in the CDC 6000 impleraentation. O.K. Before your letter, it had been 
my mistaken belief that it was important to adhere as closely as possible 
to Standard Pascal because of the argument that too nany additional features 
leads to writing programs with a greater probability of being non-standard. 
I am ""therefore glad that it is your attitude and intent to be very tight 
with extensions in your distributed version. Now I guess that the issue 
is whether Standard Pascal is a general enough language to be really 
practical in terms of portability (whereas ANSI Fortran IV doesn't even 
come close because it is not general purpose). Features were therefore 
left out of Standard Pascal which are impractical to implement on all 
machines. Is this a correct interpretation? What I meant in my last 
letter about proliferation of non-standard extensions was simply that in 
the implementations on major machines, if a feature is to be added which 
has been added in another implementation, and it can be implemented in 
exactly the same way, then it shoul,d be done the same way so as not to 
be arbitrarily different. For example the CDC 6000 implementation can 
serve as a model (since it is first on a number of features). A feature 
such as a data initialization facility if implemented in the CDC 6000 
version could be used with identical syntax by another implementation 
such as the DECsystem 10 version if it is convenient on that machine. 
By major machines I mean Burroughs 6700, etc., DECsystemlO, IBM 360/370, 
Univac 1100 series, CDC 6000/Cyber 70/170 series, and Honeywell 6000 series. 

There are many extensions to the CDC 6000 version and it is important that 
they be documented fully and in one place. (In this regard the User 
Manual is out of date.) So at our installation, our local documentation 
satisfies this need, but I want to help other installations as well. 
Maybe the Newsletter will help this. 

Another subject that I did not convey properly in my last letter was about 
the User Group and Newsletter. I did not mean to complain, but rather 
make the case for the need. And I forgot to say that we in Minnesota 
were going to volunteerl I am glad you like the idea of a Pascal User's 
Group. In fact it is now certain that we in Minnesota will be producing 
the Newsletter and doing so more regularly. George and I have talked 
several times on the phone recently about this; he will do his last 
Newsletter (#4) very soon. Our goal for the Newsletter vrlll be not only 
to maintain the quality George has set, but also to include more articles 
such as language philosophy and news of other implementations. Tenta- 
tively we want to put out a 20 page Newsletter four times a year for a 
$4.00 subscription. We will also photo-reduce contributions directly 
and not retype them. The User's Group may evolve into something official 
like STAPL for APL (under SIGPLAN auspices). George has a large aailir.g 
list in North America. I'm not so sure how to handle a large number of 
overseas members because of mailing costs. 

As to your contributions and support, they are very welcome. May I 
suggest that an official statement aboyt your policy on the CDC 6000 



implementation maintenance would make a nice article. And would it be 
possible for you and your people to directly mail us your articles in 
the future about updates, documentation, etc. , instead of us having to 
wait for the relay from George in Colorado? This will certainly help if 
we are going to put out the Newsletter. 

A week ago I obtained a copy of your new book, A -f DS - P , which I can't 
wait to finish reading! A few questions (maybe I pay too much attention 
to details) - is it the case that certain notational differences arise 
between Standard Pascal and Pascal, the publication language? Specifically, 
the symbols 7^,^ ,^ , A ,V J*™* reappear. Also,. the syntax diagram 
for field list in a record declaration has some errors in it. (See enclosed) 

It was most revealing to have read and studied your letter and I want 
to say "thanks" again. The other glimpse of where we are headed that 
proved valuable was the article which appeared this summer in SIGPLAN 
N oti ces from the proceedings of the Reliable Software Conference. If 
you have any further reactions to what I have said, I would very much 
like the privilege of seeing them. Thanks in advance! 

Happy New Year to you and your associates at the Ins ti tut fur Informatik 
from us at the University Cocaputer Center. 

Sincerely, 
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cc: U. Acuaann, G. Richmond 
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LAWRENCE BERKELEY LABORATORY 

UNIVERSITY OF CALIFORNIA 
BERKELEY, CALIFORNIA 94720 c TEL. (415) 843-2740 



rathJcCor.-Dutins Group 

LBL 

]2 Jan 75 



Andy **ickel 

U '-^inn Computer Center 

227 Exoerimental Engineerinet "Bldy 

Minneapolis 55^55 

Dear Andy — 

Thanks for your recent letter and enclosures. We (LBL) would 
certainly like to be on the nailing list of the new Pascal User^s 
Group. Addressee should be me, Ed Fourt, at the above address. 
If you M ever want to try and reach me via phone (it ain't easy), 
nimiber is (U15) 8^+3-27^40 ex 507^. 

I will put a notice in our newsletter that anyone who wishes 
to be m involved with the user's group xassti should write you. Eric 
Buchbinder, to whom you co-addressed your letter, is an enthusiastic 
user but not responsible for the maintainance of the compiler — I 
don't know his mailing address, presumably he'll send it to you. 

He have Pascal up on our 7^00, B SMKkTWBn°s?^»wv T yifJnyTBYmlmlm-s^ 
jSHaGfeBDOEKcft&S Main reason we have it is that we don't use CDC's Scope 
2, which lacks CIO, so our mods are probably of no helr> to others. 

"0F;t ha-nny to hear you're re-implement ins VALL^. Any tim.e 
estir.ates??? — I mean, when you'll have it??? ?n.3cal is damnably 
la'",^ v/ithout it, sez me. Once it's in, naybe I'll start pushinr: Pascal 
harder to the general user community — us are is probably lower here 
t'"ar. ir, really -.rarrcnted. Zh:t the big drawback to Pascal is , it 
keers on plsyin-'^ those dirty trie;::: '-•:■; "'■"^ like aboli-^'-.- .- - VALUE... 



h^nks for writing: and hope to hear from ^.o 



^ e^ -tVm^ 



UNIVERSITY OF WASHINGTON 

SEAITLE, WASHINGTON 98195 



Department of Computer Science, FR-35 January 14, 1976 



Mr. Andrew B. Mickel 

University Coraputer Center 

227 Experimental Engineering Building 

University of Minnesota 

Minneapolis, Minnesota 55455 

Dear Andy: 

Thank you kindly for your letter of January 5, 1976. I hope that you will 
place me on the mailing list of the newsletter and other mailings. Please 
send the Pascal newsletter also to: 

Computer Information Center 
Academic Computer Center 
Mail Stop FC-10 
University of Washington 
Seattle, Washington 98195 

and to Mr. Fred Dunham 

Academic Computer Center 
(address as above). 

For reference, my telephone number is (206)-543-9264. 

We are using the Pascal2 compiler from Zurich (via Colorado) on our CDC 6400- 
CYBER 73 system. In addition to the updates from Colorado (we are currently 
on Update 8), we have made a number of local modifications. The primary one 
made substantial changes in the scanner, allowing multicharacter representations 
for a number of symbols (e.g.*. ,* for ; , PTR for "uparrow", *. .= for : = , etc.). 
These were done to allow easy use of IBM 026 keypunches. Also, we have changed 
the compiler to the SCOPE 3.4.4 end-of-line convention, added line numbers to 
the listing, and a few minor things. Other changes are planned for the future, 
but will depend on student help. A copy of our Pascal announcement is enclosed. 

We would be very interested in learning more about your changes; reduction of 
compiler size is quite important to us. I am thinking also of breaking the 
compiler into overlays so that we can run in 40k (octal); have you thought 
about that? If you send me a tape of your mods, preferably in standard 
UPDATE format, we will reciprocate (please use 7 track tape, if possible). 
Could we also have your available literature? 
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page 2 



Do yoa have any experience using the FORTRAN-PASCAL linkage? I happen to 
believe that the future of PASCAL depends on two things: (a) having a 
(minimal) standard language that all implementations adhere to — perhaps as 
defined in the Revised report, and (b) in providing for all implementations 
an environment in which it is very easy to mix (sub) -programs written in 
FORTRAN and PASCAL. Any thoughts would be welcome. 

I hope to hear from you soon; thanks again for writing. When is newsletter 
No. 4 going to appear? 




Department of Computer Sciences 
Painter Hall 328 



THE UNIVERSITY OF TEXAS AT AUSTIN 

COLLEGE OF NATURAL SCIENCES 
AUSTIN, TEXAS 78712 



March 8, 1976 
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Sincerely yours. 



^juJP^ 



Hellmut Golde^ 
Professor 



HG:yi 
Enclosure 



Andy Mickel 

University Computer Center 

227 Experimental Engineering Building 

Minneapolis, Minnesota 55455 

Dear Andy, 

I am finally sending you the notes I promised you some time ago. In the mean- 
time you should have received the tape containing the BOBSW system. 

I modified our PASCAL system somewhat so that the user has knowledge about how 
much space Is used for stack and heap. A control card might look as follows: 

PASCAL2.0Fr » PT, C = 7, W = 4, B = 4. 

This gives the compiler 7K to work with, the generated program will have at \vcl^ 
4K, and the buffer size for files of type TEXT is IK, The work space is measured 
when a procedure is entered, also when an item is placed on the heap.*^ The code 
generation for measurement can be turned off. The user is now independent of 
setting the fieldlength, which may vary with compiler options or routines from 
libraries. By setting the right workspace an optimal fieldlength is achieved. 

I also fixed a bug in the code generation (see example). As this was the first 
time I really looked at the code generation I have to say I was puzzled! I just 
hope the new version will do a better job! 

About a month ago a PASCAL translator (written in ttCI-LISP) was finished. It 
does all the type checking and it produces a prefix form which is used by a 
verification system to generate verification conditions. The grammar I used 
Is Included. 

How is your PASCAL Users* group coming along? Got any new developments from 
Zurich? Please, keep me informed. Looking forward to your next newsletter, 
I remain 
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RICHARD J. CICHELLl 

901 WHITTIER DRIVE 

ALLENTOWN. PENNSYLVANIA fSlOS 



March 9, 1976 



Mr. Andy Mi eke 1 
University of Minnesota 

Computing Center 
227 Experimental Engineering Bldg. 
Minneapolis, Minnesota 55^55 



Dear Andy: 



Glad to hear you liked my paper. 



Is the newsletter going only to SIGPLAN members? 
What I*m thinking Is that if not, then you might want an 
actual Soma cube program to Include. I enclose a copy of the 
Condlct program. It's a Xerox copy of the original photo copy 
and I hope it is a good enough reproduction. The original was 
sent to (and butchered by) SIGPLAN. It might help clarify 
things. If you decid?4 to use it, I recommend you use the 
bottom half of the first page as an introduction. 

We are forming a Lehigh chapter of the Pascal 
Users Group. Joseph Mezzaroba (see attachment for description 
of some of Joe's work) of the mathematics department is the 
principal organizer. We expect about 25 active members to 
start with. You may wish to sign up the entire group to receive 
the newsletter. Joe can be contacted in care of the Mathematics 
Department, Lehigh University, Bethlehem, Pa. 

Ranee DeLong of Moravian College and I gave a talk 
to our local DEC RSX Users Group on SIL's (Systems Implementation 
Languages). We are users of PDP llJs, Discussed were: PASCAL 
(as per Per Brlnch Hansen of California Institute of Technology), 
C (Bell Labs» UNIX) and BLISS (William Wulf of Carnegie Mellon 
with HYDRA). I understand that a committee at DEC is evaluating 
SIL*3. (Committee members: Rodger Haium and Leon Spitz at DEC 
in Maynard, Mass.) They are leaning towards BLISS. I believe this 
is very unfortunate because BLISS is the most machine dependent 
of the languages under consideration. I was hoping they would 
follow the example of CDC and use PASCAL (e.g. the Series 17). 
I believe that machine dependent SIL's (called MOL's - machine 
oriented languages) are a step backwards in systems programming. 
DEC would be better off following the lead of HP, Burroughs, 
and CDC. Maybe PUG could have some Influence on this decision 
process. 



Ranee is hopeful of getting Brlnch Hansen's PASCAL 
running under UNIX. Any PUG members who have already done 
this should contact us. 

Sincerely, 



(2-J- 



Richard J. Cichelli 

R. J. Cichelli, J. Goodling, S. L. Gulden , J- Mezzaroba 

Lehigh University 

A CALCULATION OF THE HAI^^4ING WEIGHTS FOR THE BINARY CODE (73, 28) 

The binary code (73,28) Is obtained as the row space of 
the incidence matrix of the projective plane of order 8 where 
the entries of matrix are taken to be in GF(2). The number 
of non-zero vectors in this vector space is 2 -1 = 268,435,455 
A program to calculate the Hamming weight, i.e. the number of 
non-zero components, of each vector was written in the program- 
ming language PASCAL- 6000 and run on the CDC- 6400. The algorithm. 
used was a result of a series of refinements. The first algorithm 
we designed was estimated to require 20,000 CPU hours; the final 
algorithm enabled us to perform the calculations in 2 CPU hours. 
By implementing a multi-precision arithmetic program in PASCAL 
the weights of the orthogonal code (73,45) were calculated in 
about 30 seconds using the MacWilliams equations. \^e comment 
finally that the structure of PASCAL made the task of program 
design easier than had been anticipated. 
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Anyway, the talk was very well received. Most BSX 
users were surprised to find out that for any given hardware, 
UNIX supported 10 times the number of interactive users that 
DEC software did. 



Presented at Conference on Computations in Algebra and 
Number Theory 
August 24-29, 1975 
University of New Brunswick 
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UNIVERSITY OF MINNESOTA 

TWIN CITIES 



University Computer Center 

227 Experimental Engineering Building 

Minneapolis, Minnesota 55455 



March 15, 1976 



George H. Richmond 
March 15, 1976 
Page 2 



The last item is most important. Confusion proliferates especially 
as to the best IBM 360 version and where to get a Univac 1100 version. 
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George H. Richmond 

Computing Center: 3645 Marine Street 

University of Colorado 

Boulder, CO 80302 

Dear George: 



If you don't have time to write a reply please call me Friday afternoon 
612/376--7290. Thanks a lot George! Hope to see your membership soon. 

Sincerely, 
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Andy 



Even though it would have been better coming from you, we feel that 
time is running out this school year and therefore must announce the 
transition of the PASCAL Newsletter to the Pascal tlser*s Group 
ourselves. I hope this is okay with you. Just the same, the precise 
thing is happening that I didn't want: namely some people are 
already confused about the presense of the User's Group without knowing 
its relationship to the existing Newsletter. 

We have received much mail from prospective members and to this add the 
people who attended ACM *75. To broaden the base of support to users, 
teachers, etc., we are doing a mass mailing to the largest university 
Computer Science Departments and Computer Centers. Enclosed is our 
cover letter and coupon. 
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Enclosure 
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We have sent an announcement to SIGPLAN Notices ." Plans now are to issue 
the newsletter in September, November, February and Ma^ and have 
membership end on June 30 of the year. So membership is really geared 
to an academic year and we plan to send all 4 issues of a given year 
to a person who joins any time during the year. We are now soliciting 
76-77 membership. 



CD 



Now you can see that our announcement in Newsletter #4 needs revision. 

Zurich wrote to us that Release A would be ready by now but we have 
no word as to specifics, do you? 



Now that #5 is back to September, 1976, I hope that takes the pressure 
off of you. To have the best impact for the User's Group however, 
it would really help if #4 appeared no later than May. I know you v/ill 
do what you can. 

^^°» please send as soon as possible: 

a copy of your mailing list *of any PASCAL users past or present, 

the xerox copies of correspondence you have had, code corrections 
and suggestions sent you, bug reports, and examples of local 
documentation, 

any and all information on other implementations. 
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UNIVERSITY OF SOUTHERN CALIFORNIA 



UNIVERSITY COMPUTING CENTER 



1020 W. JEFFERSON BLVD. 

LOS A^iGELES, CALIFORNIA 90007 



Georgia 
Institute 
of 

- ICCrUlOlOgy school of information and computer science f {404)894-3152 I ATLANTA. GEORGIA 30332 

May 4, 1976 



GO 



April 5, 1976 



)&t. Andy Mickel 
Pascal User's Group 
UCC: 227 Exp. Engr. 
University of Minnesota 
Minneapolis, Minnesota 55455 



Andy Mickel 

University Computer Center: 227 Exp Engr 

University of Minnesota 

Minneapolis, MN 554-55 

Dear Andy: 

In your announcement of the formation of a PASCAL User^s Group, 
I came across a memo from you to Tim that states that there are 
now six IBM implementations of PASCAL. Since Tim no longer works 
here, I would like some information about these implementations. 
Would you send me information concerning where these implementations 
are, if they are available for purchase, whom to contact concerning 
each one, how they are differentiated, etc. Academic Services 
currently has a version from the University of Manitoba, but 
because of its core requirements, it is awkward to use at our 
installation. We are looking for a one-step monitor that can run 
in 120K. Do you know of any such implementation? 

I don't know how well you knew Tim, but he is currently working for 
the World Health Organization. If you care to contact him, his"^ 
address is: 

Tim Gill 

poste restante 

1211 Geneva 27 

Switzerland 

We are joining the PASCAL User's Group under separate cover. Thank 
you for any information you can supply me. 



Sincerely, 



u 



Susan L. Stallard 
Academic Services 
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Dear Mr. Mickel: 

I goofed in my note on the PUG application blank. I still need Newsletter 
j?2 (a nd ^k when you get it). 

Here at Tech, as at many places, there is a distinct separation between the 
computer center and the computer science department. The center has had the 
PASCAL compiler on the CYBER for about 15 months now, but I do not think that 
there was much use of it made. It appears that I am the first member of the 
department to promote its use. I handle the operating system series and in 
the graduate course we went through Brinch-Hansen's text so that we could then 
move on to his SOLO system during the operating system lab course. As you 

ptx)bably know, the SOLO package includes two PASCAL compilers one for 

sequential PASCAL (pretty much the standard) and one for Per's concurrent 
PASCAL. The whole thing is written for the PDP-11/45. Right now I have 
three teams trying to bring uphissytem. One of them is doing it on the 
CYBER. The approach there is to rewrite the kernel and interpreter in CYBER 
PASCAL, make the necessary interfaces to have the I/O look like the PDP-11, 
and run the whole thing under NOS. Another group is working on the Burroughs 
B-5700. They are rewritting the kemal and interpreter in ESPOL (ALGOL), and 
when they finish the Burroughs will run under SOLO alone, the MCP will not be 
used at all. The third group is working with our PDP-11 which does not have 
floating point and has some other I/O differences. All indications thus far 
are that all three groups have tasks that are comparable. 

I also have a group of special project students doing some system programming 
for the Motorola M6800. I have been pushing them into the use of PASCAL for 
the initial design of their programs. 

A couple of questions: How many updates have been issued for PASCAL 6000-3.4 
thus far? Who is distributing them now? Is that going to be Colorado or 
you in the future? I have heard some talk about a new version of PASCAL 
for the CYBER (for obvious reasons). Any other news on that? 







Philip H. Ens low, Jr. 
Associate Professor 
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Did you see the initial announcements of the new CDC line CYBER 

18? The only high level language I saw mentioned was PASCAL. ff^_ , 



HARRY M. MURPHY, JR. 

3912 HIUTON AVENUE, N.E. 

ALBUQUERQUE, NEW MEXICO 87110 

TEL; (505) 881-0519 



23 May 1976 



Pascal User's Group 

c/o Andy Mickel 

University Computing Center 

227 Experimental Engineering Building 

University of Minnesota 

Minneapolis, Minnesota 55455 
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200 Third Street: Los Alcos, California 94022 



26 May 1976 



L-os Alcos Office 
fRRC/ Structured Systems} 
W1S) 9^8-0377 
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Dear Sir: 

Please enroll n» as a member of the Pass:al User's GixHJp as announced 
in the May 1976 SIGPLAN Notices^ My personal check for $4,00 for the currant 
year is enclosed. 



My hone address and telephone number are given above | ray 
address and telephone number are: 



'official" 



PASCAL USER'S GROUP 

c/o Andy Mickel 

University Computer Center: 227 Exp Engr 

University of Minnesota 

Minneapolis, Minnesota 55455 

To Whom It May Concern: 






Air Force Weapons Laboratory 
SAT (Mr. Harry M. Murphy) 
Kirtland AFB, New Mexico 87117 
Tel: (505) 264-9317 

Ws recently acquired the Pascal 50Q0-3.4 compiler from the University 
of Colorado and now have it running on one of our CDC-^600 computers* I am 
just startdLng to investigate to what extent Pascal may be a serious compet- 
itor with FORTRAN for the writing of scientific computer programs. Until 
now» FORTRAN has been used almost exclusively for such work at AFWL. 

I selected as asy first non-trivial Pascal program a general-purpose 
weighted least-squares polynomial fitting program which reads x,y,z triplets 
froia cards (one triplet per card) and which fits second through fifteenth 
order polynomials to the data weighted according to the values of z . * 
Of course, I immediately ran into the difficulty of writing general-purpose 
procedures — such as one to solve a system of linear equations — whose 
arguments include arrays whose dimensions are not known until the procedure 
is called. This is a very serious omission from Pascal, since it implies 
a serious lack of generality in procedures processing arrays. 

I am looking forward to receiving the next issue of the Pascal 
Newsletter when it appears next September. 



Sincerely, 




,^OV-UT/0;V, 




We are currently working on one of the largest software projects undertaken in 
PASCAL. There are currently seventeen PASCAL programmers coding different parts 
of the system, and it is expected that twenty-five will be required for the 
latter phases of the project. We are using a version of. the University of 
Illinois compiler, which runs on and generates code for the DEC PDP-11/45 machines 
which are being used for both the development and target systems. The compiler 
has been extensively modified to allow the integration of separately compiled 
coda modules and data bases, to extend pure PASCAL in certain dimensions, and to 
make use of certain hardware features of the PDP-11/45 and PDP-11/70. 

Other members may be interested to learn that we have an immediate need for at 
least five programmer/analysts with PASCAL experience. Experience with compilers 
for PASCAL-like languages and with the PDP-11, along with some industrial as well 
as academic experience, would be relevant. We will be able to pay extraordinary 
fees (between $2000 and $3000 per month) for a well-qualified wizard. The 
different positions on this project are expected to last between three and ten 
months, with the possibility of further structured programming and systems work 
on other projects, according to the interest of the programmer. 

We would be very grateful if the possibilities for participation in this project 
could be brought to the attention of interested and qualified members of the 
computer science community, either through the Pascal Newsletter or in any other 
forum which seems appropriate. Interest applicants should contact David Shaw at 
(415) 966-2082 or (415) 948-0877 (messages) immediately. 

Many thanks for your assistance. We look f onward to receiving the Pascal News - 
letter , and would be grateful to receive all back issues and any membership and/or 
installation lists which may be available. Please bill us for any associated cost. 



Sincerely, 



,;:./ ^^sy---^' 
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David Elliot Shaw 
Division Manager 
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A Division of International MonitoPt Inc. 
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JET PROPULSION LABORATORY California Institute of Technology • 4800 Oak Grove Drive, Pasadena, Calijomia 91103 




UNIVERSITY OF COLORADO 

BOULDER, COLORADO 80302 



COMPUTING CENTER 

18 June 1976 



-o 

GO 



27 May 1976 

Refer to: 914. 12/2592 
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Pascal User's Group 

c/o Andy Mickel 

Univ. Computer Cntr. , 227 Exp. Engr. 

University of Minn. 

Minneapolis, MN 55455 

Dear Mr. Mickel: 

You will find enclosed my check for $4. 00 for membership in the 
Pascal User's Group. 

My own main interests are in numerical analysis and mathematical 
software. I ann a menmber of the IFIP Working Group 2. 5 on Numerical 
Software and I was editor of the SIGNUM Newsletter from 1972 through 
1975. I try to keep informied on programming language developments 
that may have significance for the developnnent of portable library-type 
nnathematical software. 

So far, the Pascal language appears to be unsuitable for this type of 
application, due to the lack of something equivalent to the adjustable 
dinaension feature of Fortran. For examiple it does not seem to be 
possible to write a library procedure in Pascal to operate on an n by n 
matrix A provided by the calling progrann. 

I would be particularly interested in obtaining information on a Pascal 
compiler for the Univac 1108. So far we do not have a Pascal connpiler 
on our JPL Univac 1108 systems. 

I wish you and your colleagues good luck in launching the Pascal News- 
letter. 

Sincerely yours, 



Dr. Charles L. Lawson, Supervisor 
Applied Mathematics Group 
MS '§!^^^m% /lSr//Z.p 



Mr. Andrew B. Mickel 

University of Minnesota 

University Coraputer Center 

227 Experimental Engineering Bldg. 

Minneapolis, Minnesota 55455 

Dear Andy: 

I have finally managed to assemble the material I promised you 
several weeks ago. The delay has been mine. Enclosed you will find a 
multitude of items including the rough draft of the fourth PASCAL News- 
letter. Let me outline them briefly. 



1. 



2. 

3. 
4. 
5. 
6. 



Various documents written by Wirth's group: "On Code 

Generation in a PASCAL Compiler", "PASCAL-S: A Subset and 

its Implementation", "The PASCAL (P) Compiler: Implementation 

Notes", and "An Axiomatic Definition of the Programming 

Language PASCAL". 

Rough draft of Newsletter 4. Please send me your comments 

as soon as you can. 

Various items associated with PASCALS. - 

Various items associated with PASCAL-P. c{i^h'i^<4^>^ 

Copies of Newsletters 1, 2, and 3. 

A computer printout of the full PASCAL mailing list 



di^UU^ 
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When I get a chance, I will make copies of all of our previous 
correspondence from Switzerland. 



Hope to hear from you soon. 



Sincerely, 



George H. Richmond 



CLL;lh 



GHR:ejh 
Enclosures 
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Telephone 354^321 



Twx 910-588-3294 
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UNIVERSITY OF llORTH CAROLINA AT CHAPEL HILL 

Depiiitment of Computer Science 

18 June 1976 



Dear Andy, 

Thairx for the information on the new PASCAL-P compilers. My 
own work is with compiler-writing systems, and I planned on using 
the P-code compiler as a base for (extensive) modifications. Doing 
so saves the hassle of me writing scanners, parsers, and other 
irrelevant (but necessary!) subroutines. 

My second goal, of course, was to install a usable PASCAL compiler 
here at UNC, In fact, just last week I installed the Stony Brook 
compiler on our 360/165 — should anyone inquire, it seems to be 
buggy. I've already sent off several bug reports; I have a few 
more sitting on my desk. Because of that, I doubt that I'll order 
the P4 compiler; I've spent too much of my department's money on 
PASCAL compilers, and I don't think they'd be too happy about yet 
another, I have completed (I think) a set ofmodifications to the P2 
version that should let me do what I want, though it is apparent that 
I will not be producing a production-quality compiler. At any rate, 
I'll wait at least until George Richmond has it available before 
making any decisions. 

Incidentally, I suspect that the PUG will (eventually) be deluged 
with requests/comments/bugs in the SUNY compiler. They are no longer 
running student jobs on a 370, and I suspect thatthey'll discontinue 
maintenance in about a year. 

I'm glad to hear that PUG is catching on. If I find time and a 
topic, maybe I'll send you an article. In the meantime, my main efforts 
(other than finishing my dissertation) are devoted to convincing people 
here to use PASCAL. 




TEXAS DEPARTMENT OF MENTAL HEALTH AND MENTAL RETARDATION 



TEXAS RESEARCH INSTITUTE Or .MftTJTAL SCIENCES 
1300 Moursund, Texas Medical Cent-ji, Houston, Tc- ^as 77020 713 797-1 



JOSEPH C, SCHOOLAR. Ph.D., 
DIRECTOR 

July 1, 1976 



Pascal User's Group 

c/o Andy Mickel 

University Computer Center: 227 Exp. Engr. 

University of Minnesota 

Minneapolis, Minnesota 55455 

Dear Andy: 

I'm happy to know that you're forming a Pascal User's Group, and am enclos- 
ing my membership dues. I don't currently have access to a Pascal Compiler, 
but hope that you can give me information on how to get one. I'm writing 
to George Richmond for a Pascal-P2 order form, but would be interested in 
leads on existing implementations for the following machines: 



CPU 



PDP 11/55 
HP 2100 
CDC 7316 



Operating 
System 

RT-11 
RTE 
Nos. 1.0 



Main Memory 
(words) 

32K Core 
32K Core 
131 K 



Disk Capacity 
(Bytes) 

5 Meg. Disc. 
4.8M Disc. 
Plenty 



/ 



I'm most interested in getting Pascal for the PDP 11/55. This system will 
be used for signal analysis of biological signals such as EEG and evoked 
potentials. I hope to use Pascal for applications and system level program- 
ming instead of Fortran. 

The rapid proliferation of Pascal without support from a major manufacturer is 
the most encouraging note I've seen in several years. I hope that the User's 
Group can keep the mementum up while providing an arena for discussion of pro- 
blems, improvements, standardization, portability, etc. I hope to hear from 
you soon and am looking forward to the Newsletter in September. Thank you for 
your help. 

Sincerely, 
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-Steve 



(*Steve Bellovin*) 



James A. Kendall 
Psychophysiology Section 
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-.a 27 514 Telephone 919-913- 



An Equal Opportunitv/Affirmative Action Employer 




The University of Calgary 



2920 24 AVE. N.W. 
fb CALGARY, CANADA 

yy:^ T2n in4 



DEPARTMENT OF COMPUTER SCIENCE 
TELEPHONE: (403) 284-6316 



July 22, 1976. 



Andy Mickel, P.U.G. , 
UCC: 227 Exp. Engr., 
University of Minnesota, 
MINNEAPOLIS, MN 55455, 
U.S.A. 



ABT ASSOCIATES INC- 

55 WHEELER STREET, CAMBRIDGE. MASSACHUSETTS 02l3e 
TCUEPMONE • AREA « 1 7 - 4 » a • "? 1 O O 



23 July 1976 



Andy Mickel 
PASCAL Users' Group 
UCC: 227 Exp. Engr. 
University of Minnesota 
Minneapolis, MN 55455 
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Dear Andy, 

At the University of Calgary, Pascal is mainly a teaching 
language. I've been working with it heavily in my research on 
several fronts mainly as the vehicle for a program to solve Go 
problems. 

Some students here have taken the Pascal 1 compiler 
as a base and have developed a very interesting language of their 
own in the attempt to firm up a number of Pascal's rather obvious 
clay feet. Anyone interested in this kind of thing should direct 
an enquiry to Mr. James Gosling; I won't steal their thunder here. 

Like most of us , I suppose, I am not a "professional 
Pascal programmer" (what a droll concept!) but just a person who 
has found Pascal an excellent vehicle for my thoughts; of all the 
programming languages I have available, it is the "least bad". 
But it isn't the best. 

When talking about this lovely language with skeptical 
physicists and the like, the rock I always founder on is that Pascal 
is incompatible with Fortran. One can't write Pascal subroutines 
to be called by Fortran, one can't use named common, and one must 
use a run- time-stack. Hence, potential Pascal users have to convert 
everything or forget it. 

They forget it, and this seems sad to me. If a Pascal 
implementation could go into direct competition with Fortran, I 
believe the world would benefit. And I see nothing in the Pascal 
language to forbid the development of such an implementation, given 
^a convention for named common ("own", if you prefer), a "nonrecursive" 
attribute for procedures and functions and something to allow the 
passing of arrays when the subprogram must be given the dope vector 
at run time. 

Surely all this is obvious, and I'm just writing it 
to ask: Who out there has written a Fortran-subverting Pascal 
compiler? 



Dear Andy: 

Thank you very much for the mods you sent me in the mail, and 
the nice phone call. However, I feel it my duty to take you 
to task over a small issue, the form of your modsets. Although 
MODIFY is in many ways superior to UPDATE as a library mainten- 
ance tool. PASCAL is distributed in UPDATE format, and in fact 
mods in the past have always been sent out in UPDATE format. 
If we are to be serious in our attempts to bring about the revo- 
lution in computing we support, we must take extra efforts in 
the direction of standardization. 

The reason for the "heat" is that, although several, if not all, 
of the modifications you sent will be useful to us, the number- 
ing scheme (MODIFY' s) is completely incompatible with the form 
in which we maintain our compiler (UPDATE), and cannot be installed 
without a great expenditure of time and effort. 

I would therefore like to propose a "standard for interchange" of 
modifications and extensions to PASCAL-6000: 

• All modsets would be in UPDATE compatible form. 

t All modsets would be based upon Release 2 and would state 
all dependencies upon other modsets. 

• All modsets would contain, as a minimum, the name and 
institution of the author, the date of the mod, and a 
brief explanation of the extension/correction. 

I would also like to suggest the formation of a "standards com- 
.mittee" which would review proposed extensions and modifications 
Vor compatibility with the spirit and letter of PASCAL. Although 
this may seem unnecessarily formal, without some standard (and 
regulated growth), PASCAL will become another BASIC, a hodge-podge 
with so much variation that it is almost guaranteed that one man's 
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Very truly yours , 
Stephen Soule. 



BASIC program will not run (or even compile) on another man's 
machine. Should this happen, the possibility that PASCAL will 
replace or compete with FORTRAN will remain only a dream. 

I would like to recommend that Nick Wirth be involved in this 
effort, and e^ery attempt be made to solicit ACM involvement and 
sponsorship of the standard. With the rapid growth of PASCAL, 
the time to strike is now. Waiting for an indigenous group of 
PASCAL users or manufacturers to sponsor such an attempt might 
prove to be disappointing. 

To further the development of the interchange standard, I have 
enclosed a small tape on which I wish you would write the modsets 
you presently have (the ones you sent me) in UPDATE compatible 
form. I would be yery grateful if you would then return the 
tape to me for inclusion in our compiler. 

Sincerely yours. 




Michael Patrick FTagerty 
Director of Systems Research 
and Design 



P.S. Add to the three points earlier that mods to the Zurich 
compiler should be made through one centralized distribu- 
tion point, so that the "willy-nilly" exchange will not 
become a stumbling block to development of interesting 
ideas and features. 



EXTRA PAGE: 



This note, written a day after the previous two pages is to 
serve as an apology for the harshness of the earlier text. 
I do hope that those comments will not be interpreted as a 
personal assault, but as constructive and supportive of your 
present efforts. Sort of like a call to "gird up your loins." 

In the meantime I have had another opportunity to go over the 
listings you sent, and would like to suggest that the formatted 
read routines for real and integer be included in a manner 
similar to the formatted write routines: 

READ (f, I:w, R:w:d) 

This should prove useful in the business community, and allow 
them to move away from PICTURES in COBOL. 

I also had the chance to look through Urs' masterpiece, and 
noticed that the VAR declarations are stored, as you said. In 
push-down order (LIFO). I thought you mentioned something 
about a mod to reverse this order, and after looking though 
the modsets you sent, I did not find one. If you have a modset 
which allocates the items left to right, I wouTd appreciate 
receiving a copy of that set as well. 

Assuming that you will find time to produce the document, "U of 
M PASCAL User's Guide," I would be overjoyed to receive a copy 
when it is completed. 



Thanks again for the material and the call, 
a long and close relationship, I remain 

Sincerely yours. 



Looking forward to 
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P.S. Good luck on getting the mods that were to become Release 
3 out of Nick and Urs. Those mods, with the e^fe"^^ and 
structure initialization from your shop, will prove to be 
wery powerful indeed. 







Dr. Niklaus Wirth 
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23 July 1976 



UNIVERSITY or COLORADO 

BOULDER. COLORADO 80302 



COMPUTING CENTER 

23 July 1976 



Dr. Niklaus Wirth 

Eidgenossische Technische Hochschule 

Institut fur Informatik 

Clausiusstrasse 55 

ai-8006 Zurich, Switzerland 

Dear Dr. Wirth: 

I appreciate your concern expressed in your letter of 17 June 1976, 
so I will clarify my position (and that of the Computing Center) with regard 
to PASCAL. 



In the long run, it may be possible for the PASCAL User's Group to 
become a self-supporting organization like VIM (for CDC users) and Sii^E (for 
IBM users). At that point, we should consider turning over distribution of 
PASCAL (for all machines) to them. 

I hope this letter will clarify my position and put your mind at 
ease somewhat. I am most enthusiastic about PASCAL and hope to see it grow 
with- each passing year. 

Sincerely, 



A^'H.M^ 



George H 
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cc: vA. Mickel 



Recently, I have been working long hours on other projects. That 
situation has eased somewhat. Also, interest in PASCAL has grown over the 
years so that some of the responsibilities that I initially carried have 
been shifted and others will follow. The result has been slow response to 
letters and orders. That situation will improve as things get better organized 
here. 

The first change was to involve our group's able secretary, Jan 
Hurst, in several aspects of PASCAL. For the last year, she has been -pro- 
cessing orders for PASCAL2 and now PASCALS. 

The second step was the PASCAL Newsletter. One of the problems 
was the irregular intervals at which it was published. Andy Mickel has now 
assumed that duty and promises to put the newsletter on a regular basis. As 
material for a newsletter has been accumulating for over a year, I agreed to 
publish one more- newsletter- Urs Ammann recently received a rough draft 
and I hope to have the fourth newsletter in the mail to you about 1 August 
and back from the printers in bulk by mid-August. 

The third change was to select a distributor for Australia (and 
surrounding regions) that would serve the same purpose as I do in the U.S.A. 
Overseas mailings have always been a problem in shipment time, reliability 
of delivery, postage costs, and completion of payments. Carroll Morgan has 
assumed this position now. 

That leaves Jan and me with the filling of orders and mailing of 
corrections for PASCAL (CDC and portable versions) in the United States. 
This task is manageable and we will continue to do it. Once the fourth news- 
letter is out, the remaining problem will be cleaned out. 



m 



CO 

m 



en 



en 



The IMPLEMENTATION NOTES section of the newsletter is organized as follows: 

1) A checklist for more information about distributed implementations of 

of Standard Pascal . 

2) Information concerning Pascal~P, a "portable" compiler of Pascal for a 

hypothetical "stack machine". It comes on tape as a kit and is used 
to produce compilers for real computer systems. 

3) Other portable compilers: Pascal Trunk compiler, PASCAL-0, and Pascal-S. 

4) Information about compilers for real computers sorted by computer system . 

(*Note: We simply don't have enough implementation/distribution information. People 
especially need to know those things that will make them intelligent "consumers" of 
Standard Pascal systems (see POLICY section inside front cover). One need not adhere 
to a rigid format when sending this information for inclusion in the newsletter. 
However it would probably be a great thing to follow the checklist below, and if you 
desire, supply a short order form (both "camera-ready"). Users of particular 
implementations are encouraged to share their experiences by sending qualitative and 
quantitative descriptions. Attach either of these (distribution info or experiences) 
to an ALL PURPOSE COUPON. Please realize that individual requests to me for 
implementation information outside the context of the newsletter will be a great 
hassle. 

I must apologize for the incomplete nature of the information following. 
It will take at least until Newsletter #6 to get fully organized. By far the most 
requests that have come to me have been for DECsystem 10, PDP-11, and IBM 360/370 
Pascal compilers. This issue of the newsletter will concentrate on those and a few 
others. -Andy*) 

CHECKLIST 

1. Names and addresses and phone numbers of impTementors , maintainers, distributors 

2. machine(s) (manufacturer, model/series) 

3. operating system(s), minimal hardware configuration, etc. 

4. method of distribution (cost, magnetic tape formats, etc.) 

5. documentation available (machine retrievable?, in form of supplement to the 

the book Pascal User Manual and Report? ) 

6. maintenance policy (for how long? future development plans? accept bug reports?) 

7. fully implements Standard Pascal? (why not? what's different?) 

8. compiler or interpreter? (written in what language? length in source lines, 

compiler or interpreter size in words or bytes (specify base) of _bits, 

compilation speed in characters/second, compilation speed compared to other 
language processors (e.g. FORTRAN), execution speed compared to other language 
processors (e.g. FOl^TRAN)) 

9. reliability of compiler or interpreter (poor, moderate, good, excellent) 

10. method of compiler or interpreter development (from Pascal-P, hand coded from 

scratch, bootstrapped, cross-compiled, etc; effort to implement man 

months, experience of implementors) 



PASCAL-P 



EIDGENOSStSCHE 
TECHNISCHE HOCHSCHULE ZORICH 

Institut fiir Informatik 

Clausiusstrasse 55 

CH - 8006 Zurich 

/ 01 / 32 62 11 

A new release of the P^SCAL-P system. 



Terminology: 
Pascal PI: either of the early Pascal P systems (released in 

March and July 1973 respectively). 
Pascal P2: the Pascal P system released in May 74. 
Pascal P3: the new Pascal P system with the same hypotnetical 

machine as the one underlying the Pascal P2 system. 
Pascal P4: the new Pascal P system with a slightly modified 

liypothetical machine (allowing a more efficent 

implementation) . 



Pascal P3 
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still generate 
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improved in many details. It does, however, 
code for the old P2 assembler interpreter. The 

of the P3 system are: 
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rds of the assembly code produced by the 

terminated by the symbol 'O ' instead of two 

gs are corrected. 

t independence. 

s are included (indexing, assignement to 

iables, and case selection are checked for 

functions 'succ' and 'pred' are implemented, 
fault conventions 'readln = readln ( input) ' 



Pascal P4 
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Explanations of the installation parameters 



intsize,realsize,charsize,boolsize,setsize,ptrsize: 

Number of addressable storage units to be reserved for 
variables of type integer, real, character, boolean, set, 
pointer. As to 'setsize', remember that a set must be able 
to hold at least 48 elements if you intend to use the system 
to bootstrap the compiler. 

intal,realal,charal ,boolal,setal,ptral : 

Variables of the corresponding types will be given an 
address which is a multiple of these alignment constants. 

stackelsize: Minimum size for a value on the expression stack. 
The expression stack is that portion of the stack which is 
used for the evaluation of expressions. 'Stackelsize' has to 
be equal to or a multiple of 'stackal'. 

stackal: Alignment constant for a valu on the expression stack. 
'stackal' must be a multiple of all other alignment 
constants and must be less or equal to 'stackelsize'. 

strglgth: Maximum length of a string, {in fact all strings will 
be of length 'strglgth'), A string must be able to hold the . 
character representation of a number (real or integer) with 
its sign. The minimum length for a bootstrap is 12. 

intbits: Number of bits used for representing an integer without 
the sign. So the largest integer is 

intbits 
2-1 

sethigh,setlow: Maximum and minimum ordinal values for the 
element of a set. 



Format of the Tape 

No . of tracks 

Density 

parity 

Physical record length 



\ 



Code: 



second octal 
\ digit 
first \. 



800 bpi 

odd 

5120 frames 

the last physical record of a 

file may be shorter than 

5120 frames. 
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The end of line is represented as a series of two to eleven 00 
frames. 

The last eight frames of a file have no meaning (the last 8 
frames of the trailing short record of a file) . 



Interrecord gap : 3/4" 

End of file gap : 6" 

End of information = 2 end of file gaps 
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ordmaxchar rordminchar : Maximum and minimum ordinal values of the 
character set. 
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lignment conditions there may be two 
the assignment of store on top of the 

nt requires the same amount of store: In this 
ize' has to be greater than or equal to the 

other size constants, (Remember : 'stackelsize' 
of 'stackal') 

e: A new element on the expression stack has 
t the next position allowed by the alignment 
kal'. In this case 'stackelsize' has to be 
qual to the maximum of the other size 



The handling charges include the costs for generating the binary 
versions of the compiler, a minitape, and postage. 



with kind regards 
Ch. Jacobi 
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IMPLEMENTATION NOTES 



(Source information. Proposals for extensions to Standard Pascal. 
Bug Reports. Program writing tools, etc.) 



We order 



Order form for the revised Pascal P system. 



Please provide us with your revised Pascal P system according to 
the specifications on next page. 



Address for delivery of the system 



The characteristics of our installation are 
Machine type 
Operating system 



Installation parameters (to be filled for case 'A' and 'b' 
below) 



A [^ (For new users of Pascal P or users of the Pascal PI 
system) 

- Pascal P4 compiler(in Pascal). 

- Pascal P4 compiler (in P4 code), 

- An assembler interpreter of P4 code (in Pascal, for 
documentation purposes, all alignement and size 
constants are set to 1 ) . 

- Pascal P compiler implementation notes with update 
list. 

Charge SFr 160.- 

B Q] (For users of the Pascal P2 system) 

- All of the above package, plus: 

- Pascal P3 compiler (in Pascal). 

- Pascal P3 compiler (in P3 code, = P2 code). 

- Pascal P4 compiler (in P3 code). (1/2 bootstrap, for 
compilation on the P2 machine of test programs for the 
P4 interpreter.) 

- A file containinq the changes made with line numbers. 
Charge SFr 290.- 

C Ll (For users who have access to a CDC 6000 Computer and 
want to experiment with the compiler) 

- Pascal P4 compiler with some changes, so that it is 
accepted by the Pascal 6000 compiler (in Pascal). (All 
installation parameters set to a standard value.) 

- An assembler interpreter (in Pascal, as in package 
'A'). 

- Pascal P compiler implementation notes with update 
list. 

Charge SFr 80,- 
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intsize 

realsize 

charsize 

boolsize 

ptrsize 

setsize 

stackelsize 

strglgth 

intbits 

sethigh 

ordmaxchar 



intal 

realal 

charal 

boolal 

ptral 

setal 

stackal 



setlow 
ordminchar 



{*Note: prices are most certainly different in the Americas and Australia 
more next newsletter.*) 

Signature : 
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If you are in Europe, Asia, or Africa, order Pascal -P from: 

Ch. Oacobi 

Institut fur Informatik 

E.T.H.-Zentrum 

CH-8092 Zurich 

Switzerland (phone: 01/ 32 62 11) 



In North or South America: 

George H. Richmond 

Computing Center: 3645 Marine St, 

University of Colorado 

Boulder, CO 80309 USA (phone: (303) 492-8131) 

(note change in address and phone) 



In Australia: 

Carroll Morgan 

Basser Department of Computer Science 

University of Sydney 

Sydney, N.S.W. 2006 Australia 
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Please fill out and return at your earliest convenience. 



Your address: •• Our address: Institut fur Informatik 

• • • PASCAL~P Questionnaire 

ETH-Zentrum 

CH-8Q92 Zurich 

0. Do you want to be kept on our PA5CAL~P mailing list ? | | yes 1 I no 

1 ♦ Will you order or have you ordered the June 1976 versi on 

of our PA5CAL-P system? [ | yes | { no 

2. Did you receive an earlier version of our PA5CAL-P 

system? dj yes I ] no(exit ) 

3. Which version? □ March 1973 □ July 1973 CH May 1974 

4. This PA5CAL-P system 

I 1 was never installed. Reason: 



t I was installed and was operating, but isn^t used any more. 
Reason: •••••••.««••«.•••• 



(exit) 



(exit) 



j J is operating. 

5. I I It is interpretive. The interpreter is written in ..........(language). 

I I It was bootstrapped. Method : .... ..•.•••.•••.••.••...•• 



6. The total effort to bring this PASCAL system to the present state was 
.....•••.... .man-months. 



7. Comparison of compilation requirements: 



programming 
language 


space: number of kilo-words 
needed by compiler 


speed: number of character pro- 
cessed per central processor 
second 


PASCAL 






FORTRAN 















Tha maximum number of central memory words available for a single job is 
....... K words (1 kilo-word = 1 K words = IOOO^q words). 

A central memory word has bits. 

8. Comparison of execution requirements: 



programming 
language 


kilo-words needed 
by runtime support 


compactness of code 

(>1 <i>compacter than FTN ) 


speed (>1 ^'quicker 
tharr FORTRAN) 


PASCAL 








FORTRAN 




1 


1 
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9. The actual length of the PASCAL compiler is •••♦•.• source lines, 
The number of replaced or inserted lines is . . • 

10. The reliability of the compiler is 

[ I poor f I moderate | [ good 

1K The use of PASCAL is Q batch 

12. The PASCAL system is used for 
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i [ excellent 
I I interactive. 



purpose 


usage 


none 


little 


moderate 


extensive 


experimenting 










student courses 










production 























13. Tendency of usage: | [ increasing \ \ stable | [ decreasing 

l^* Standard PASCAL constructs which are not available: 

I I program heading | | several standard procedures/functions 

r 1 formal procedures/functions | | sets of the form [<exp> . • <exp>] 

□ ^^ii^- a ........ 



15. Local extensions of PASCAL are 



16. The PASCAL system is running 

on a ..••••••••«• •«••••••••••••••••• (machine type) 

under ♦..•• •••••••.•• .,. •••.•••.«••.•• (operating system) 



17. The main problem with the PASCAL system is 



18. Do you distribute your PASCAL system? Ql yes 

19. The PASCAL system was sent to ....places. 

exit: Comments :..••••••••• •• 



I I no(exit) 



Thank you for your collaboration! 



5 March 1975 



5 March 1975^ 



(*Note: This is old, Pascal -P2 ordering information from George Richmond for 

persons in the Americas. It is included here to provide further details 
which are certainly similar for Pascal-P3 and Pascal-P4.*) 



The PASCAL-P Distribution Tape 

The PASCAL-P distribution tape may contain either an unconfigured or 
configured version of the PASCAL~P compiler. The tape may be written as 
a CDC binary format tape (800 bpi, 7 track, NRZI, odd parity, 5120 
character records), as a blocked BCD format tape (800 bpi, 7 track, 
NRZI, even parity, 1600 character records), or as a nine track tape 
(1600 bpi, 9 track, PE, 1600 character records). Your tape is: 

Unconfigured 

Configured 

CDC format 

BCD format 

Nine-track format 

U nconfigured Compiler 

The unconfigured tape contains three files of information followed by 
the same three files again as a duplicate in case of a tape error. The 
contents of the three files are: 

File 1 Interpreter 

File 2 Unconfigured Compiler 

File 3 Editor * 

The interpreter is a non-o perational Pascal program which documents 
how to interpret P-code. The interpreter reads P-code from a file and 
stores it in memory. Then it interprets the P-code for execution. 

The unconfigured compiler is written in Pascal and generates P-code 
for output instead of machine code. This compiler is unconfigured 
because of the double dollar signs ($$) placed in the text for 
replacement by the editor. To produce a compiler system instead of an 
interpreter system, the code generators must be rewritten for the target 
machine. 



Configured Compile r 

The configured tape contains three files of information followed by 
the same three again as a duplicate in case of a tape error. The 
contents of the three files are: 

File 1 Interpreter 

File 2 Configured Compiler 

File 3 P-code Compiler 

The interpreter is the same one that is on the unconfigured tape. 

The configured compiler is the second version output by the editor as 
described above. It has the configuration parameters supplied with the 
order for PASCAL-P inserted into the unconfigured compiler. 

The P-code compiler is written in P-code. It is the output of the 
PASCAL-P compiler run mentioned above. It is equivalent to the result 
of running the configured compiler in file 2 against itself. Once a P- 
code interpreter is constructed, it should be possible to compile the 
compiler and produce the same P-code as in file 3. 

Character Sets 

The attached character set table indicates the correspondence between 
Pascal graphics and code combinations on tape. At the left, ETH PASCAL- 
P is the graphics used in this system. Column A is used for CDC format 
tapes. Column B is used for blocked BCD format tapes. And column C is 
used for nine-track format tapes. 

Note 

For BCD and nine-track format tapes, the record size is 80 characters 
blocked 20 for a block size of 1600 characters. It is unfortunate that 
some of the lines of the unconfigured and configured compiler source are 
longer that 80 characters. These long lines will appear as two 
consecutive 80 character records. Depending upon the text manipulation 
facilities available at your installation, you may rebuild the long 
lines or split the source statement at a more appropriate point. 
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The editor reads the unconfigured compiler and configuration 
parcimeters and produces two versions of the compiler. The first version 
is acceptable to the standard Pascal compiler for CDC machines and the 
second one is acceptable to the PASCAL-P compiler. The first one is 
compiled and run on a CDC machine. The second one is accepted as input 
to the first PASCAL-P compiler and P-code is generated for the target 
machine. 
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PASCAL Trunk Compiler 

In 1975, H. H. Nageli developed a "trunk" compiler to help transport Pascal 
compilers to other machines. The trunk is a source program of a compiler written 
in Pascal, in which machine dependent parts are marked and clearly separated from 
machine independent parts, and detailed comnents are provided for an implementor 
how to describe algorithms for these machine dependent parts. For example, Teruo 
Hikita of the University of Tokyo used Pascal -P to interpret the trunk compiler 
modified for the IBM 350 compatible Hitachi Hitac 8000 series, with very good results. 

H. H. Na'geli is at the Institut fur Informatik, E.T.H., Zurich. 

PASCALJ 

The Software Engineering Group at the University of Colorado Department of 
Electrical Engineering has implemented a Pascal compiler which generates JANUS 
intermediate code. The "mobile programming system" JANUS is totally portable - even 
to the point of defining its own character set. It is available on several computers 
such as the CDC6400 and the Xerox Sigma 3. There have been several releases of 
PASCALJ: September, 1975, February ," 1976, and one for this m.onth, September, 1976. 
Write B.W. Ravenel or C.B. Mason for distribution information at: 

Software Engineering Group, Department of Electical Engineering, University of 
Colorado, Boulder, CO 80309 



AMDAHL 470 (see IBM 360/370 series) 

BURROUGHS B-1700 (implementations exist) 

B-3700. B-4700 (implementations exist) 

B-5700 (implementations exist) 

B-6700 Several implementations are listed below: 

A.H.J. Sale of The University of Tasmania, G.P.O. Box 252C, Hobart, Tasmania 
Australia 7001 (phone 23 0561) is known to have developed 
a compiler based on Pascal -P2. 

Kenneth L. Bowles of the University of California, San Diego computer center 

La Jolla, CA 92037 (phone (714) 452-4050) had a Pascal interpreter 
running but is now more interested in a good PDP-11 implementation. 

6. Goos of the Institut fuer Informatik II, 75 Karlsruhe 1, Zirkel 2 Germany, 
implemented a compiler based on Pascal -PI, and hence may not be 
standard. However our information is almost 2 years old and this 
implementation may have been upgraded. 

CI I IRIS 80. 10070 (see Xerox Sigma 7) 
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PASCAL-S 

As documented in the report: "PASCAL-S: A Subset and its Implementation", June, 1975 by 
Niklaus Wirth of the Institut flir Informatik, E.T.H. Zurich, PASCAL-S defines 
an official subset to be used to aid in teaching programming. The abstract of 
the report is given below: 

"Pascal -S is a subset of the programming language Pascal selected for 
introductory programming courses. This report describes an implementation 
that is especially designed to provide comprehensive and transparent error 
diagnostics and economical service for large numbers of small jobs. The 
system consists of a compiler and an interpreter and is defined as a single, 
self-contained Pascal program. This machine-independent formulation in a 
high-level language facilitates its construction and is a prerequisite for 
easy portability." 

Standard Pascal constructs omitted in Pascal-S are: scalar and subrange types, pointers, 
set and file types, with and goto statements, the passing of procedures and 
functions as parameters, and several standard procedures. The only file operations 
are read on input and write on output. The report contains a complete listing 
of the compiler and interpreter on 34 pages! 

Pascal-S is currently distributed on tape with the second release of the CDC 
6000 Pascal compiler and is written to run under that version. However, Ed Katz 
of the University of Southwestern Louisiana, Lafayette reports that his department 
implemented Pascal-S from the report in PL/1 for Honeywell Multics in a semester, 
(see HERE AND THERE) 



CONTROL DATA cyber 18 (an implementation exists) 

2550 (Control Data supports a cross-compiler on the 6000/Cyber 70,170) 
3300 (implementations exist) 
3600 (an implementation exists) 
5000/CYBER 70.170 SERIES 

This implementation has been developed by Urs Ammann of E.T.H. in Zurich for the 
last 3h years. Release 1 of the compiler (named Pascal 6000 - 3.4) appeared in 
May, 1974, and was updated 10 times over the next Ih years. Release 2 appeared in 
March, 1976 which incorporated a massive update to Release 1, updatelO to improve 
performance and reduce memory requirements. An error message sumnary is provided 
at the bottom of the listing and a working version of the procedure DISPOSE is 
included. 

A new Report describing the implementation is entitled: "On Code Generation in a 
Pascal Compiler" by Urs Amnann, April, 1976, 40 pages. 

Pascal 6000 - 3.4 was produced by rewriting an older compiler and bootstrapping. 
It is the first Standard Pascal compiler and its documentation is in the last two 
chapters of the user manual part of the book: Pascal User Manual and Report . 

The Release 2 compiler may be run under SCOPE 3.4, KRONOS 2.1, or N0S,N0S/BE 
operating systems. It may be edited to change it to 63/64 and ASCII subset character 
sets. 

The compiler is a 7000 line Pascal program plus operating system interface 
routines. Its core requirements are 45000 octal words of 60 bits each for small 
programs, but this rises to 57000 octal to compile itself. Compilation speed is 
about 10500 characters/second on a Cyber 74; 54 seconds of processor time are 
required to recompile the compiler on a Cyber 74. Its efficiency compares 
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favorably to FORTRAN; compiling speed and compute bound execution speed being about 
1.3 times slower^ but I/O execution speed being clearly faster. Its reliability 
has improved to being excellent, and there are only a few minor bugs outstanding. 

Pascal 6000 - 3.4 features a number of extensions to Standard Pascal, and only 
three restrictions. One may not use a file of files; segmented is a reserved word; 
and standard (built-in) procedures or functions are not accepted as actual parameters 
to other procedures or functions. 

Distribution is. currently being handled in Europe, Asia, and Africa by Urs Ammann, 
Institut fur Informatik, E.T.H. - Zentrum, CH-8092 Zurich, Switzerland. In 
Australia, contact Carroll Morgan, University of Sydney, Basser Department of Computer 
Science, Sydney N.S.W. Australia 2006. Costs for these distribution points are 
unknown; tape format is unlabelled, 7-track Scope internal binary. 

For North and South America only, another contact point is George Richmond, 
Computing Center 3545 Marine Street, University of Colorado, Boulder, CO 80309. 
Information for the distribution from Mr. Richmond is as follows. Included in the 
documentation package are: 

Literature about the Progranming Language Pascal (4 pages) 
The ReleaseZ Distribution Tape (3 pages) 
Note on the Tape Contents (13 pages) 
Pascal: User Manual and Report (170 pages) 

An Axiomatic Definition of the Programming Language Pascal (32 pages) 
Cost for Release 2 with documentation is $50 (by check or purchase order) and $10 
additional for a 600 foot magnetic tape if one is not supplied. Because of the 
similarity in documentation betv^een Release 1 and Release 25 a special offer is 
extended by Mr. Richmond to previous recipients of Release 1 who want to upgrade. 
For $25 and your supplying a 500 foot tape^ and the documents: The Release 2 
Distribution Tape and Literature about the Programming Language Pascal. No other 
material has changed. 

Sent with Release 2 is also the Pascal -S subset compiler and the 'document: 
PASCAL-S: A Subset and its Implementation (63 pages). 

The tape format will be seven track SCOPE 3.4 internal binary and unlabelled 
(equivalent to KRONOS 2.1 MT5F=SI,LB=KU). At special request, and at no extra 
cost, KRONOS formats F=I or F=X can be used. In the near future, nine track 
binary tapes vrill be available. 

The future of the compiler maintenance is uncertain at this writing. Send bug 
reports to: John P. Strait, University Computer Center, 227 Exp Engr, University 
of Minnesota, Minneapolis, MN 55455 USA, or call (612) 375-7290. 

Several persons have made modifications to Release 2 for operating system 
interaction. Interactive facilities under KRONOS Telex have been developed by 
John P. Strait at the University of Minnesota. An agreement is underway with 
George Richmond so that these mods can be distributed through George Richmond for 
the Americas. Michael Hagerty has developed mods for SCOPE 3.2 systems and 
for INTERCOM. He wants these to be distributed centrally and as yet no agreement 
has been reached. Mr. T.A. Nemeth of the Computing Centre, University of Adelaide 
has written mods (no language changes) for SCOPE 3.4 and INTERCOM. They are 
available for $A10+postage from North Terrace, Adelaide, S.A. 5000 AUSTRALIA. 

Hans J^raandstad of CERN announced changes to put Pascal Release 1 up on 7600 
and Cyber 76 systems under the SCOPE 2.1.2 operating system (where Record Manager 
is used because no CIO exists.) There is no distributions information at present. 

See the next page for the order form for George Richmond's distribution only. 

Future development plans are also uncertain for Pascal 6000 - 3.4. Several 
complaints keep echoing over and over. For example Albert Steiner of the 
Vogelback Computer Center, Northwestern University wrote on 4/26/76: 1) Sets 
ought to be implemented for more than 59 members. 2) Better storage control and 
management of dynamic allocation is needed - such as obtaining additional 
dynamic storage if needed, perhaps in conjunction with a manageable OVERLAY or 
SEGMENT loading scheme. More news next time. 



SOFTWARE WRITING TOOLS for the CDC Pascal 6000 - 3.4 implementation have been 
around. The first such program is a cross-reference utility for producing a numbered 
source listing with an index to identifiers. The program usually known as XREF 
was written by Niklaus Wirth, and has been modified several times over the years, 
most recently for the second release of the compiler. XREF is written in standard 
Pascal (just over 200 lines), is small and efficient. The 7000 line Pascal compiler 
with sequence numbers (making each line 90 characters long) took 17.8 seconds to 
cross reference on a Cyber 74. 

Several pretty-print or indenting programs for Pascal programs have been written. 
At Indiana University, George Cohn wrote RASCAL (Reformat Pascal) which has 
three options: I for setting indent width, R to select reformatting mode (indenting 
style) and W to set output width. RASCAL is written as a 1267 card Pascal program 
(fully RASCALed). (218 cards fully compressed by itself!) (*ICEBOLed?*) 

The most circulated pretty-printer is Michael Condi ct's FORMAT program, written 
at Lehigh'University. Like RASCAL, FORMAT allows options to be imbedded in 
special conments. Additionally, the user may specify a file for these directives. 
Options include: A for specifying right justification width of identifiers in 
declarations;, E for selecting block bracket commenting such as end (*procname*). 
E also can add consents to for , case , while , and j_r statements. G specifies 
spacing between symbols, I specifies indenting width, L for amount of indent on 
statement wrap-around, P number of blank lines between procedures, S number of 
blanks between two statements on the same line, R input width limits, W output 
width limits, N write line numbers on FORMATted output, B compress program 
(*ICEBOL it*), C combine more than one statement per line if possible, D select 
or deselect outputting of source, and F eliminate formatting and copy verbatim. 

Both RASCAL and FORMAT are copyright. FORMAT has been sent to educational 
institutions, and perhaps in the future, a distribution agreement can be set up. 

At the University of Minnesota, a program for pretty printing is being 
developed called SPRUCE. At the University of California., Berkeley, a pretty 
printer is called PPRINT. 

All the pretty print programs so far suffer from the ability to recover from 
syntactically incorrect Pascal programs. Comments in the input are generally not 
handled very well either. 

The University of Massachusetts has been working on a "Pascal Assistant" to 
make interactive programming in Pascal more pleasant. Henry Ledgard, Andrew Singer, 
and Jon Hueras have developed this system to run under NOS. A User's Guide has 
been written. 

N. Solntseff of McMaster University, Hamilton,, Ontario, Canada L8S 4K1, Dept. 
of Applied Mathematics has sent a report describing EDITABSLIB. It is designed 
to maintain a library of complete Pascal programs in binary form. Entitled 
"A Suite of CDC6400 Control -Statement Procedures for the Maintenance of a Binary- 
Deck Library", its abstract follows: 

"This report describes the implerientation and gives examples of the use 
of EDITABSLIB, a library-maintenance system which allows a user to 
assemble and maintain libraries of program modules which do not 
meet the requirements of the standard SCOPE EDITLIB system, namely, 
Pascal 6000 and COBOL core-image modules, as well as binary (or source) 
modules of a "minicomputer support system". EDITABSLIB can be 
used in the batch mode, as well as interactively via INTERCOM. 
It represents a complete library-maintenance system." 
EDITABSLIB is currently running under SCOPE 3.4.3 and a program to manipulate 
the loader prefixtable for the library is written in Pascal. 
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Release 2 of Pascal 5000-3.4 Distribution Tape 
(Use this only if you are in North America or South America.) 

The tape prepared for you by the University of Colorado Computing 
Center is an unlabeled tape of the following format: 



O MT, F=SI, D=HY 

O ^'Kr F = lf D=HY 

O MT, F=X, D=HY 

O OTHER: _____ 



Scope standard binary, seven track 
Kronos internal binary, seven track 
Kronos external binary, seven track 



The tape contains seven files of information following by another 
seven files of the same information. Instructions for installing the 
Release 2. system can be found in the first file of information. 



In order to offer maintenance of the Pascal System the University of 
Colorado Computing Center needs the name and address of a responsible 
party. Please fill out the bottom of this form and return it to: 

Mr. George H. Richmond 
University of Colorado 
Computing Center 
3645 Marine Street 
Boulder, Colorado 80309 
USA 



Pascal will be maintained by: 

Name : 

Address: 



Zip Code 



CRAY RESEARCH CRAY-1 (No information yet.) 

DATA GENERAL nova 800. nova 1200. supernova, eclipse 

(No reported implementations - but we need information!) 
DIGITAL EQUIPMENT (DEC) PDP-8 (No known implementations) 

PDP-11 

In wading through the morass of information on PDP-11 versions of Pascal, we 
found that although many implementations (too many) exist or are in development, 
very little concrete data is available on operating system and hardware requirements. 
Distribution and maintenance for most versions remain a mystery. We hope to provide 
more meaningful summaries in forthcoming issues, and to this end we solicit comments 
from implementors/distributors/maintainers/users - please refer to the CHECKLIST. 

Following is the information we do have. We have an obligation to provide you 
with complete, up-to-date implementation news, and so will print skimpy descriptions 
only once. 

First and foremost. Per Brinch Hansen has implemented both "sequential Pascal" 
and his "Concurrent Pascal" for the PDP-11/45. These compilers, written in Pascal, 
run under the Solo operating system, which itself is written in Concurrent Pascal. 
A portable version of Concurrent Pascal also exists. Manuals, reports, and 
distribution tapes have been available from Per Brinch Hansen, Information Science 
286-80, California Institute of Technology, Pasadena, CA 91125. However, Richard 
Cichelli has reported that Brinch Hansen has moved to the U of Southern California 
and is no longer distributing Pascal. (*How about it. Per?*) 

The Pascal Group at the University of Illinois has a completed version of Pascal 
for the PDP-11/20, running DOS. Although this version seems to be the most widely 
distributed, it departs widely from Standard Pascal: a) No type set or real, b) 
No packed arrays , c) Arrays and records must be passed by reference, d) Many non- 
standard character set equivalences are allowed, e) Many abbreviations for reserved 
words are allowed, f) Compiler options do not follow the convention of (*$ options*), 
g) Else allowed on case statements, h) Unconventional extensions have been made to 
the standard procedures read and write, i) The assignment operator may be used in 
expressions, introducing semantic ambiguities in evaluation of certain expressions. 
These differences disallow many programs written in Standard Pascal, having serious 
consequences for software portability. For more information write: Pascal Group, 
267 DCL, University of Illinois, Urbana, IL 61801. 

Electro Scientific Industries has completed a compiler for the PDP-11/04 with 
RT-11. This compiler, written in MACRO-11 assembly language, was based on the 
University of Illinois implementation. Arthur A. Brown has informed us that this 
version is available for $1500. Excerpts from a paper by David Rowland describing 
ESI's use of Pascal appeared in Newsletter #4. Write or telephone: David Rowland. 
Electro Scientific Industries, 13900 N.W. Science Park Drive, Portland, OR 97229, 
(503) 646-4141 

C. Bron and W. deVries have implemented a cross-compiler from the DEC-10 to any 
member of the PDP-11 series. There are no operating system requirements for the 
PDP-11 used. It appears that this version, which was developed from Pascal -P, 
closely implements Standard Pascal with the exception of files. The compiler 
generates absolute load-modules in "position independent" code. The development of 
this compiler is described in "A PASCAL Compiler for PDP-11 Minicomputers", 
SOFTWARE - Practice and Experience , Vol. 6, pp. 109-116 (1976). The system is available 
on 9-track magnetic tape or on DEC-tape (two reels are necessary) and can be obtained 
—free of charge - by anyone who sends a tape (please do not send tape as parcel, 
but as letter) to C. Bron or J. Entrop, Dept. of Electrical Engineering, Twente 
University of Technology, P.O. Box 217, Enschede, Netherlands. Five files will be 
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written on the tape - the compiler's source code, a documentation file, the text 
of the runtime support in PAL-11, the code of the runtime support in compiler input 
format, and an auxiliary program to transform output from the MACRO-11 assembler 
into compiler input format. The latter two files are only relevant for those who 
wish to alter the existing runtime-package. 

A Pascal compiler based on JANUS has been implemented on the POP 11/45 running 
under DOS/Batch operating system. This compiler, written in Pascal, generates code 
for the standard abstract machine JANUS. William Waite's macro processor STAGE2 is 
used to translate JANUS into the MACRO-11 assembly language. The compiler compiles 
itself in 64K words of memory and 604 seconds. The Pascal compiler, Stage2, the 
Pascal -11 User's Guide, and the whole Pascal -11 system are available from: Lucien 
Feiereisen, Institut f. Biokybernetic u. Biomed. Technik, Universitaet Karlsruhe 
D-7500 Karlsuhe 1, Kaiserstrass 12, Germany. ,, . . 

The remainder of the implementation information is skimpy. The following is a 
list of addresses and short notes: . ^ ,, », .. r- -tj mm ccact 

Timothy W. Hoel , Academic Computer Center. St. Olaf College, Northfield, MN 55057 
(507) 663-3096: "I know of (*a Pascal compiler running under the UNIX operating^^ 
system*) which is a 7-pass translator producing C-code, the mam HLL under UNIX. 

Arthur A. Brown, Apt. 1002, 1101 New Hampshire Ave. NW, Washington, DC^20037, 
(202) 785-0716: "I am currently trying to introduce Pascal in my company's roster 
of languages, and intend to implement it on a minicomputer of my own during the 
coming year (*PDP-ll/04*)" - 27 May 1976. ,_^^ ^^^ ^^^^ 

Andrew S. Puchrik, 11623 Charter Oaks #202, Reston, VA 22090, (703) 893-4330: 
"My company (INCO, Inc.) has ordered the Solo Operating System from Cal Tech. 
"I plan to run the (sequential) compiler under RSX-llD. (We just got version 6B.) 
The first problem is to emulate a floating point processor or patch-up the compiler. 
We don't have the f.p.p. on our 11/45." - 24 April 76. 

W. H. Huggins, Department of E.E., The Johns Hopkins University, Baltimore, MD 
21218: Tim Hoel informed us in August that W.H. Huggins has a version of sequential 
Pascal which runs under UNIX and produces PDP-11 machine code. Huggins will send 
it for $150 and a photo copy of Brinch Hansen's Solo contract. 

Henry Spencer, Box 302 Sub 6 , Saskatoon, Sask. S7N OWO Canada, implementation 
in progress with P-code on PDP-11 under UNIX" - October, 1975. e- • 

Kenneth L. Bowles, Dept. of Physics and Information Science, Computer Science 
Division, C-014, University of California, San Diego, La Jolla, CA 92093, (714) 
452-4050: Bowles is working on an interpretive sustem based on Pascal-P. He hopes 
to be able to modify the compiler to allow it to run in 20K or perpaps 16K words 
of memory for the PDP-11. See his letter to A.H.J. Sale printed in Newsletter #4. 

H. H. NHgeli of E.T.H., Zurich reports that the Pascal Trunk compiler is being 
used'to write a cross compiler for the PDP-11 in zOrich. 

Gordon Stuart, Camosun College, Technical and Vocational Institute, 1950 
Lansdowne Road, V-ictoria, B.C. V8P 5J2 Canada: Implementing version for the PDP-11/40 
status unknown, as of 3 March 76. ^ . « 4. j « 

Andrew S. Tannenbaum, Wiskundig Seminarium, Der Vnje Umversiteir, ^sterdam - 
1001 Postbus 7161, De BoeTelaan 1081, Netherlands: Implementing version for PDP-11/45 
status unknown as of 7 February 76. 

DEC SYSTEM-10. PDP-10 

For the last several years, H.-H. Nagel of the Institut fiir Informatik, Universitat 
Hamburg has implemented DEC-10 compilers -for Pascal. The one most widely in 
circulation comes as a dual system: PASCAL is a compiler which produces shared 
(.SHR) and low (.LOW) segments directly, and the other compiler PASREL, produces 
relocatable code which can be processed by the loader into shared and low segments. 
The relocatable compiler, PASREL, has more predefined procedures and functions 
available than the PASCAL compiler and has a powerful interactive debugging package. 



These compilers are being improved with respect to efficiency, standardization, 
and the addition of still missing or desirable language features. H.-H. Nagel 
wrote on June 14, 1976: "We are just introducing a new version of the 
DECSystem-lO Pascal compiler. I hope to be able to send some information about 
this compiler to you in the near future." 

Documentation for the system comes on tape. In February, 1976, Wilhelm Burger 
of the University of Texas produced a technical report (22B) with Nagel in English 
entitled: "PASCAL on the DECIO". From this report we find that interactive use 
of Pascal is described, and that there are several serious omissions from Standard 
Pascal. They are: a) No label declarations are allowed, b) Not all ASCII characters 
are allowed - specifically control characters, c) The program declaration is not 
implemented, and d) Procedures and functions cannot be formal parameters. 
However subroutine linkage in PASREL is provided for assembler, Algol, Cobol , and 
Fortran programs! 

We have no performance/comparison data available. The compiler runs under TOPS-10. 

The method of distribution is in the form of a chain of sites passing a tape 
from one to the other - a chain. We have no cost information. In Europe write to 
H.-H. Nagel, Institut fur Informatik, SchluterstraBe 70, D-2000 Hamburg 13, Germany. 
In the US and Canada write to Wally Wedel or Wilhelm Burger, Computation Center, 
University of Texas at Austin, Austin, TX 78712. Please specify if you are on a 
chain. Shipment requires either a DECtape for the PASCAL compiler and 2 DECtapes 
for the PASREL compiler, PASDDT, crossreferencing program CROSS, and PASCAL-Help 
file in German. 1 MAGtape can be supplied instead of the DECtapes but DECtapes 
are preferred. Please indicate if you are willing to be part of the distribution 
chain - that is whether you are willing to provide a copy of these files to someone 
else if asked to do so. 

Perhaps the proposed new release of the compiler(s) will see an improvement 
in implementation and distribution information. 

Complaints about the DEC-10 implementation are from Jim McCool , lUPUI, Computing 
Services, 1100 W. Michigan, Indianapolis, IN 46202 (317) 264-3836 who writes: 
"We are currently searching for a reliable version of PASCAL for the DEC-10 computer. 
We have the release from the University of Hamburg, but have found it completely 
unsatisfactory. I am writing you in the hope that, as the head (sic) of the 
Pascal User's Group, you might know of some other implementation of the language 
for the DEC-10." ("^pretty strong, although vague stuff.*) 

Charles Hedrick, 183 Commerce West, University of Illinois, Urbana, IL 61801, 
(217) 333-4515, and (217) 356-8425 writes: "About the DECIO PASCAL (PASREL, actually) 
I understand it was an undergraduate class project. As such it is very good. It is 
fast and generates fairly good code. However it does not follow the usual 
conventions for DECIO compilers, and in general is not well adapted to the DECIO 
operating system: 1) Programs cannot simply be loaded and run as with other 
languages. Core must be explicitly allocated, something that complicates 
explaining its use to students. I realize that for efficiency reasons, they did not 
want to have dynamic expansion of core, but the least they could do is start with 
some default amount greater than that would let simple programs run (e.g. the 4K 
recommended in the (German language) help file). I have put such a patch in our 
local version. 2) The compiler cannot be called by the DECIO compiler-caller COMPIL. 
This means that the monitor commands COMPILE, EXECUTE, etc. cannot be used. Rather 
the compiler must be explicitly run, and then the loader must be invoked. Again, 
an inconvenience with beginners. 3) Lower case characters are ignored everywhere - 
is source code, comments, strings, filenames, everywhere! 4) A file OUTPUT is 
created on your disk area even when no output is done to the default channel (or 
at all!) This file has a "DATE75 error", that is its creation date is 5-Jan-74, 
whatever the current date. 5) A listing file is always created, and cannot be 
surpressed. This file is largely useless, as it is usually just a copy of the 
source. 6) Options to the compiler are included in the source code as comments... 
DECIO convention is to use "switches" after the file name. E.g. to get a listing 
one says .EXECUTE FILE. PAS/LIST. COMPIL passes on the command string to the 
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compiler: FILE. REL, FILE. LST=FILE.PAS/L. 7) Parameter passing in procedures is full 
of bugs: e.g. type foo = packed array [I..IOJ of char; 

procedure foobar(a:foo; orinteger, c: integer, d:foo, e: integer); 
(*body*); 
(*etc*) 

foobar('ABCDEFGHIv3M,2,'IJKLMNOPQR',3); will assign some large 
negative number to parameter e in foobar. We have fixed this bug, but it is only 
a minor manifestation of generally poor design of parameter passing. The following 
case is harder to fix, and we haven't done so. (It would seem to require a complete 
rewrite of procedure linkage: procedure foo(a: real, b: real); and then 
foo(1.0,sin(0.0)); (I think it may only fail if there are more than 5 parameters to 
the procedure.) Calling sin clobbers the display which is being set up for the 
call of foo, and so the parameters, etc. are garbaged. 8) When a program wants to 
input a real number, typing 1 or even 1. causes a fatal error. This makes it hard 
to write programs to be used by non- computer programmers. DEC FORTRAN and all the 
other languages I know, do the type conversion. At least PASCAL'S runtime should 
let you retype the number rather than blowing up. 9) the KI-10 instruction set is 
not used. When using a lot of mixed type arithmetic, I have speeded up execution 
time by a factor of 2 by replacing calls to routines for integer- to-real and vice 
versa with the equivalent machine operations (FIX and FlOATR). 

FOXBORO FOX-1 (an implementation exists) 

FUJITSU FACOM 230-38 (an implementation exists) 

FACOM 230~55 (an implementation is underway) 

HEWLETT PACKARD HP-2100 (no known implementations) 
HP"3000 (no known implementations) 

HITACHI HITAC 8800/8700 (see IBM 36O/370 series) 



HONEYWELL series 6 
H316 



(an implementation is being considered) 

(an implementation is underway by Honeywell Corporate 
Research in Bloomington, Minnesota) 



600/6000 SERIES 

Robert A. Stryk of Honeywell Corporate Research (612) 887-4356 reports that 
The University of Waterloo has implemented Pascal on the 6000 series. Honeywell 
Information Services in Phoenix, Arizona has purchased it and is offering it as 
a standard software product under revision H of the GCOS operating system. Because 
it is a supported product, it will cost money - how much is not known. - July 15, 
1976. 



IBM SYSTEM 350/370 



There are three implementations for which there is detailed information. Most 
impressive is the University of Tokyo's Hitac 8000 implementation which will run 



on either the Amdahl 470 or the IBM 360/370. The following correspondence describes 
that version. 

Following that is a description of the University of Maniboba IBM 360/370 compiler. 
It has been in the development stage until recently. It features stability and 
compatibility with OS. 

A widely publicized but less efficient version of Pascal is one from SUNY Stony 
Brook. It has received criticism for poor reliability. 

There have been many requests for IBM 360 implementations. The volume of 
information reproduced here is in response. From a performance standpoint, the 
compiler by Teruo Hikita and Kiyoshi Ishihata is excellent. It is written in 
Pascal, requires only llOK bytes and is only beat in execution speed by the Fortran 
compiler at full optimization. It is well documented by two reports. The only 
problems at the present are distribution. Although we have not heard from Mr. 
Hikita since May 17, it would be nice for a site (such as Southern Cal ) to aid 
in its distribution in North America. It was Susan Stallard's letter (see OPEN 
FORUM) which stated a desire to see a version with smaller core requirements than 
the Manitoba Pascal compiler. 



February 21 » 1976 



Mr. A. B. Mickel 

University of Minnesota 

Computer Center 

227 Experimental Eng. 81 dg. 

Minneapolis. Mi. 55455 

U.S.A. 

Dear Mr. Mickel; 

This is a short notice on our recent implementation of PASCAL based on a 
"trunk" compiler. Dr. H. H. Naegeli told us to send It to you for the 
PASCAL Newsletter. (Please see an enclosed copy of his letter.) 

An extended version of Standard PASCAL named PASCAL 8000 was designed, 
and its compiler was implemented on a Japanese computer HITAC 8800/8700 
at the Computer Center of the University of Tokyo. This computer is a 
multi -processor system of 4 CPU with 4 megabytes main memory, and it has 
a quite similar machine instruction set to that of the IBM 360 and 370 
series computers. 

Our language extensions are concerned with constant definitions for 
structured types, variable initializations, new control structures named 
"forall" and "loop" statements, and "procedure skeletons" for procedure 
and function parameters proposed by Lecarme-Desjardins. 

The implementation was done by bootstrapping using the PASCAL-P interpretive 
compiler developed by U. Ammann. Our new compiler is based on H. H. 
Naegeli 's "trunk" compiler. This is a source program of a PASCAL compiler 
written itself in PASCAL, in which machine dependent parts (code generation, 
addressing, etc.) are marked and strictly separated from other machine 
independent parts, and detailed comments are provided which indicate the 
data or algorithms to be described to the final form by an actual 
implementor. The version we used was still at developmental stage, 
though almost completed. 
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About 1200 lines of the source program have been rewritten to the final 
form for our HITAC 8800/8700 out of total 5260 lines, and about 400 
lines have been newly added for our own language features. This amount 
of rewriting is considered to be fairly small compared with other works 
of bootstrapping appeared in the literatures, and one of the values of 
the trunk compiler of course lies in this point. We felt difficulty 
during the rewriting process mainly in the expression evaluation scheme. 
For the other parts, the coding was rather simple and straightforward, 
though not trivial . 

For the details of the language definition of PASCAL 8000 and its 
implementation based on the trunk, the following two technical reports 
will be available from our department in March. 

T. Hikita, K. Ishihata, PASCAL 8000 Reference Manual. 

K. Ishihata, T. Hikita, Bootstrapping PASCAL Using a Trunk. 



T. Hikita, K. Ishihata 
Department of Information Science 
Faculty of Science 
University of Tokyo 
Tokyo 113 Japan 



Dear Mr. A. B. Mickel, 



Sincerely, 

Teruo Hikita 

Klyoshi Ishihata 
March 24, 1975 



UNIVERSITY OF MINNESOTA university Computor Center 
TVViN CITIES 227 Experimental Engineering Building 

Minneapolis, Minnesota 55455 



March 31, 1976 



Prof. Teruo Hikita 

Information Science Laboratories 

Faculty of Science 

University of Tokyo 

2-11-16 Yayoi, Bunkyo-Ku 

Tokyo, 113 JAPAN 

Dear Prof. Teruo, 

Thanks to both you and your colleague, Mr. Ishihata for coming forward 
with the Hitac 8800 implementation information for PASCAL. I recently 
received both your March 24 letter and the copies of the Technical 
Reports. 

I assure you that the new PASCAL Newsletter shall publicize the Hitac 
8800 version properly. In this regard, are you willing to distribute 
the system formally and will you accept bug reports? 

I hope that you will be willing to join the PASCAL User's Group. I'm 
sorry in fact to be so late in answering you, but this was due to delays 
in setting up P.U.G. and in transferring the editorship duties of the 
Newsletter. 
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I have sent to you under separate cover the following two technical 
reports on our recent implementation of PASCAL, which I mentioned in my 
recent short notice for the PASCAL Newsletter: 

"PASCAL 8000 Reference Manual" 
"Bootstrapping PASCAL Using a Trunk" 

They have been prepared rather hurriedly, and there do remain several 
typographical errors. But we believe our Implementation details would 
be clear from these reports. 



Thank you very much. 
Sincerely, 



Andrew B. Mickel 
ABM/kp 



Sincerely Yours, 



Enclosures 
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Teruo Hikita 



INFORMATION SCIENCE LABORATORIES 

FACULTY OF SCIENCE, UNIVERSITY OF TOKYO 
2-11-16 YAYOI. BUNKYO-KU TOKYO, 113 JAPAN 



UNIVERSITY OF MINNESOTA university Computer Center 
TWIN CITIES 227 Experimental Ens-neoring Building 

Minneapolis, Mmnesota 55455 
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April 16. 1976 

Prof. Andy Mickel 

University Computer Center: 227 Exp Engr 

University of Minnesota 

Minneapolis, MH 55455 

U.S.A. 

Dear Prof. Hickel, • 

Thank you for your March 31 letter with information on the "f^ /^f ^]^ 
User's Group. I am glad to hear it, and of course I would like to join 
it. I enclosed a required coupon and a check in this letter. 

As for the distribution of our Hitac 8800 version Pascal, we are ready 
'to d?stribu?e'the system formally and ^f ^P^.^.jJ^/ef rts Ac ua^l^^ we 
have iust comoleted its transportation to another Hitac SDOu series 
computer Although the Hitac 8800 is a Oapanese computer rather ocally 
Ssed in the world! its machine instruction set is almost compatible to 
fhl^lv ifin and 370 series computers, and we may plan the slight modifi- 
^ation^of thelystemlmafnly i?s interface with the operating system) to 
cope with the IBM systems. 

I aooreciate your kind suggestion and information. I am looking forward 
to the publication of the'new Pascal Newsletter in September. 



Thank you very much. 



Sincerely, 



X 




Teruo'Hikita 



Enclosures 

TH/mk 



April 29, 197o 
Dsar Teruo, 

Tlianks for joining FUG.' We now have over 100 menibero and I*m looking 
forward to the first newsletter. 

Your 50od news about willingness to distribute your compiler is ver^' 

important I think. As you may know there are at least 6 IBM 3^0/370 Pascal 

compilers but they all seen very unsatisfactory. I know of 3 which are 

standard, . 2 take 180K E>'te3 and are nulti-pass and ths other is not ready 

yet, (oUir/ Stony Brook, U of I-knitoba, and New Mexico Tech). Also I've been 

receiving many requests for IBM 3^0 versions by/ias.Tibers of the User's Group, 

It is my opinion that your compiler, being of high quality could be the 

answer and to ease the distribution natter in this country-, it night be wise 

to find a friendly installation who could in turn pass it on to others. 

The r»ost detailed request has coT.e from: Hs, Susan L. Stallard 

Academic Services 
University Computing Center 
University of Southern Califomiz 
Los Angeles, CA 9000? 

rlaybe you could send her yo»ir Tech Reports together with the information 

about your intention to making an IBM-compatible version. 

With the information explosion, 1*11 have to br> putting together a list 
of questions to ask of .everj' iniplerienter about an i.'.-.plii-en Ration and so I 
plan to^send this list to you before oepfcf^irber. Thlr> way I can print i^uch 
j.:-:for.~ ->.tio'" in th^ ^^■•'•.ilett^r in a. st'inrlra^.^ forn. 

It his b^en a clep.sure to receiv? yoi)r r;ror!ipt and tirr.ely letters. 

Sincerely, 
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KcirUA.^: ^.^.(y-,!.^, ^m\^tA.^\<^UUt. 
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8.1. Performance of the compiler 



DEPARTMENT OF INFORMATION SCIENCE 

FACULTY OF SCIENCE. UNIVERStTY OF TOKYO 
2-IM6 YAYOI, BUNKYO-KU TOKYO. 113 JAPAN 



May 17, 1976 

Andy Mickel 

University Computer Center: 

University of Minnesota 

Minneapolis, MN 55455 

U.S.A. 



227 Exp Engr 



Dear Andyj 

Thank you for your April 29 letter, and I am sorry for writing you a bit 
late. 

We have received some other inquiries besides yours on the possibility 
of distributing our Pascal system, and we are just to begin the modification 
of the system. The only difficulty is the difference between the operating 
systems of our Hitac 8800/8700 and IBM 360/370 line computers. It will 
take at least one month to finally prepare a distribution tape. 

By the way, I should note that I am not so optimistic on the transportation 
of our system. One reason is that our compiler does not generate a load 
module of IBM systems, but rather it generates absolute (not relocatable) 
code. Secondly, I am afraid whether we can easily find a friendly 
institution who handles the distribution. 

Anyway, I will be writing to you again at the completion of the work 
above. We would like to consider at that time on the possibility of 
distributing our system in the U.S. 

Thank you. 

Sincerely, 



Teruo Hikita 
Research Associate 

TH/yk 



In the reference [15] is given several experimental data on the 
performance of the PASCAL compiler for CDC 6000. The execution times 
on the HITAC 8800/8700 for the same four test programs written in PASCAL 
and FORTRAN are shown in the following table. The result is that the 
PASCAL program runs faster than the corresponding FORTRAN program compiled 
without optimization, which shows that PASCAL can actually be implemented 
efficiently. But it is slower than the FORTRAN program compiled by a 
full-optimizing compiler by factor of 2-4 in case of small non-recursive 
programs. For the recursive programs such as "Partition", PASCAL programs 
run as fast as those of FORTRAN, probably because of the overhead of 
moving the data to and from the hand-coded stack in FORTRAN programs, 
compared with that of the automatic stack allocation of variables in PASCAL. 

PASCAL 8000 PASCAL-P(R+) PASCAL-P(R-) FORTRAN (0) F0RTRAN(2) 



Matmult 5.18 sec. 
(n=100) 



Sort 

(n=2000) 

Count 



Partition 
(n=30) 



7.98 

70.76 

0.59 



93.87 
121.54 



3.01 



79.93 
119.94 



2.81 



6.91 
13.86 



0.77 



1.36 

3.46 

56.71 

0.50 



PASCAL 8000 
PASCAL-P (R+) 
PASCAL-P(R-) 
FORTRAN (0) 
FORTRAN (2) 



without runtime error checking 

with runtime error checking 

without runtime error checking 

without optimization (Hitachi 0S7 FORTRAN OPT=0) 

with optimization (Hitachi OS 7 FORTRAN 0PT=2) 
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.2. Statistical data of the compiler 
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The size of the current version of the compiler is about 110 kilo- 
bytes, in which machine instructions occupy 89.8% and constants 10.2%. 



UNIVERSITY OF MINNESOTA 

TWIN CITIES 



University Computer Center 

227 Experimental Engineering Buifding 

IVlinneapolis, Minnesota 55455 




THE UNIVERSITY OF MANITOBA 
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April 5, 1976 



Prof. J. M. Wells 

Department of Computer Science 

University of Manitoba 

Winnipeg, Manitoba 

CANADA 



DEPARTMENT OF COMPUTER SCIENCE 



WINNIPEG. CANADA R3T 2N2 

15 Jxily 1976 

Ph. (204) 474.-81+66 
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Dear Prof. Wells, 

We understand you have a PASCAL compiler for the IBM 360/370 series 
machines. Because this is an important implementation to publicize 
in the PASCAL User*s Group Newsletter, I'm now writing to find out 
detailed information. 

There are at least 6 IBM 360 implementations I know of. Three seem 
to have been based on the revised version of the language and are 
compilers: yours, and the ones from PASCAL Compiler Project, Dept. 
of Computer Science, SUNY at Stony Brook, Stony Brook, NY 11794 and 
Prof. Thomas S. Nartker, Dept. of Computer Science, New Mexico Tech, 
Socorro, NM 87801. Were you aware of the existence of the other 
implementations and if so, how good are they compared with your system? 

Are you willing to distribute your system to other sites for a nominal 
handling charge, provide documentation, and accept bug reports? 

I really look forward to hearing from you. 
User's Group information 

Sincerely, 



Enclosed is some PASCAL 



dl 
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B. Mi 



Andrew B. Mickel 

ABM/kp 

Enclosure 



Mr. Andy Mickel 
Pascal User's Group 
University Computer Center 
227 Exp. Engr. 
University of Minnesota 
Minneapolis ? Minnesota 
U.S.A. 55U55 

Dear Mr. Mickel: 

I am answering your letter of April 5, 1976 to Professor James Wells. 
I have been preparing a new release of the Manitoba PASCAL Compiler 
and therefore waited until this was complete so that I could send you 
the latest information. 

A restricted release was made in December, 1975 to ten test sites. 
Work on the Compiler has continued and a new release is now generally 
available under the conditions set out in the enclosed description. 

The reports "MANITOBA PASCAL USER GUIDE" and "MANITOBA PASCAL CODE 
GE^[ERATXON" are included on the distribution tape in upper and lower 
case with printer control characters so that copies can be run off 
locally . 

I wrote to Professor Nartker at New Mexico Tech. concerning their 
compiler. It seems that they are debugging statements and expressions 
and hope to have the compiler running by the New Year. 

I ordered the SUNY compiler for comparison with ours. In the areas of 
cost, ease of installation, compile speed, compile-time error messages, 
formatting capability, distributed documentation, standard scalar t3rpes, 
and compatibility with OS conventions, I think the Manitoba PASCAL 
Compiler is superior. 

cont ' d . . . . 2 
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Mr. Andy Mickel 



15 July 1976 



'C:^ U J : 



UNIVERSITY OF MINNESOTA , university Computer Center 
TWIN CITIES I 227 Experimental Engineering Building 

Minneapolis, Minnesota 55455 

(612) 373 4360 
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To date, thirteen copies of the Manitoba PASCAL Compiler have been 
distributed to sites in Canada, the United States, and Europe. 



July 26, 1976 



There has not been a Pascal Newsletter since the announcement of the 
initial release was sent to George Richmond, and the Compiler has 
therefore received very little advertising. 

Although the Compiler is released on an "as is" basis, a complimentary 
copy is being sent to the initial test sites which answered a questionaire, 
and is being offered to the other sites. 

Intensive local testing led to the discovery of several problems in the 
initial release, but only one "bug" was reported by one of the test sites 
in six months of use. 

I hope the enclosed information reaches you in time for inclusion in the 
September Newsletter. I would appreciate it if you would acknowledge 
receipt of this information. 



Thank you for your interest. 



Sincerely, 



^^-^, ^^ 



W. Bruce Foulkes 



WBF:emr 



Csar Bruce, 

You doQ*t know how anich I appreciate your waiting to send such complate 
InfoTjaation on your Paiacal coapiler, Ihanks very aruch! Rest assured that 
we will devote space in the Newsletter to It. Thank you very much also for 
joining: the User's Group, Vfe now have 291 members • 

Until your letter and enclosures arrived there was much mystery in my 
mind about IBM 36O/37O ^scal implementations when it came to recommending 
one to scmebody. This is because I knew little about yours} all 1 had 
received was a complaint ftrom Southern Cal that I6OK bytes was too large. 
Ti\m SUHY Stony Brook compiler did not impress me in that l) it was written 
in XPL, 2) It was large and slow, and 3) Several people now have reported 
bugs to m« and say that it will become unsupported in a few months. I 
reeeivad a \h page faded xerox of their doctiaentation. 

I received a phone call fttsm New Mexico Tech and found out about thair 
project. 

What my interest you, is that a very high q\2ality compiler israleaenting 
all the aspects of standard Pascal for an Hitachi 8800 (Amdahl ifr70/IBM 370) , 
has been written in Japan. It is only beat out in efficiency by the Fortran 
compiler at full optimization. It ia written in i^cal, and takes llOKbytes. 
They have produced two nice technical reports which you may want to writ* 

^^^ Pascal 8000 Reference Manual Version 1.0 
Bootstrapping Pascal Using a Trunk 

The people arei Teruo Hikita and Kiyoshi Ishihata 
Dapartment of Information Science 
University of Tokyo 
2-11-16 Yayoi, Bunkyo-Ku 
Tokyo, 113 JAPAN 

Olieiircurrent work is adapting the compiler to run on standard IBM 37O 
operating systems. 

What alarms me, now that in the last few months I've learned about many 
other Biscal implementations, is that one of the design goals of I^scal is 
being subverted! najfely that of being a vehicle of portable software. Taking 
standard Pascal, onl/ i^scal 6OOO (for CJDC) and this Hitachi 8000 compiler 
will accept standard programs. The PDP 11, BSG 10, your IBM 37O, and etc., 
are restricted in a small number of fundamental areas. It wouldn't matter if 
the details were esoteric- But let's look at yours fcxr examples 

• some standard identifiers are reserved words 

. packed structures are not allowed (the symbol packed could be ignored) 

. no program declaration, no GET and PUT, comments are /* */ instead of 
(* *) , no character subranges, no square brackets [] and ] 

What's the deauL? • . 

Well, I'm just pointing some things out and don't want to sound too 
negative. TJianks again for your service in sending these things. 
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MANITOBA PASCAL CO^Tt'ILER 



A PASCAL Compiler for IBM 360/370 computers has been developed by 

the Department of Computer Science at the University of Manitoha. The 

Compiler v;as written by V/. Bruce Foulkes under the supervision of 
Professor James M. "Jells. 

Jhe Compiler is one-pass and uses a top-down parsing strategy. A 
generated assembler parser is produced by the translator writing system 
SYKTICS. All semantic routines are written in PL360 and system interfaces 
are written in Assembler. 

The Compiler is not a rewrite, modification, or bootstrap of any 
previous PASCAL compiler. The Compiler uses some routines provided by 
the SYNTICS system and borrows some ideas and code from the ALGOL W 
compiler for code generation, built-in functions, and I/O. 

The distributed version of the Compiler requires approximately 
180K bytes of memory. This size is variable, but the minimum size for 
compiling a meaningful program is approximately 160K bytes. 

The design strategy has resulted in a very fast compile speed, 
averaging more than 200 lines of source per second on an IBZ-l 370/158. 

Considerable effort has been spent on localized optimizations in 
areas such as array subscripting, record field accessing, and boolean 
expression evaluation, with the aim of producing a compiler suitable for 
the compilation of application programs. 

Extensive compile-time checking is performed and approximately 130 
different error and warning messages are provided. 

The production of run-time checking code for array subscripts, 
subrange assignments, values returned by PRED and SUCC, etc., can be turned 
on or off on a line-by-line basis. There are approximately 40 run-time 
error messages. Each error diagnostic consists of an error message, the 
location in the current segment, the invalid value if appropriate, and a 
traceback of all segments invoked. 

The Compiler produces OS-compatible object modules and uses standard 
IBM linkage and parameter lists in calls of external routines. This 
allows many existing library routines, such as CALCO>a'. plot routines, etc., 
to be called from a PASCAL program. 

The Compiler supports a subset of the language described by 
Kathleen Jensen and Nicklaus Wirth in "PASCAL User Manual and Report". 
The main differences are listed below. 

- Only the standard input and output files SYSIN and SYSPRIHT are 
supported. All I/O is done through the use of READ, READLN, V/RITE, 
WRITELN, EOLN, and EO^. The I/O is not exactly standard; in 
particular, formatting is also alloi/ed on input. 



- PACKEO nrr;r/s mid records are not supported. 

- Only the simple forms of procedures Nr:v; and DISPOSE are allowed. 
Tagficld values must not be specified. No garbaj\o. collocfion if; 
perf oriued . 

- Global Inbels arc not implemented. 

- Subranges of characters are not allowed. 

There are two main limitations imposed by the Compiler. The maximum nest 
allowed for procedure and function declarations is 5, and all program 
segments are restricted to AK bytes of code. 

Seven standard scalar types are provided: SHORT INTEGER, INTEGER, 
REAL, LONG REAL, BOOLEAN, CHAR, and STRING. 

Built-in functions include: ABS, SQRT, EXP, LN, LOG, SIN, COS, ARCTAN, 
SQR, SUCC, PRED, ODD, ROUOT, TRUNC, ORD, CILR, CAPJ), CPUTUIE, lAI.'D, lOR, XOR, 
SLA, SRA, SLL, and SRL. 

The source for the Compiler initialization routine is provided. This 
routine sets the size limits for all coraoile-tirae tables, and also sets 
defaults for compiler flags (such as whether run-time checking code is to 
be produced). This should allow the Compiler to be tailored to suit the 
needs of any installation. 

An initial release of the Manitoba PASCAL Version 1 Compiler x>?as made 
in December 1975 to approximately ten sites. Work on the Compiler has 
continued and a new release is now generally available. The Compiler has 
undergone considerable usage and has proven to be quite reliable. 

A distribution fee of $50.00 (payable to the "Department of Computer 
Science, University of Manitoba") is required to cover our distribution 
costs, including a 600-foot 9-track distribution tape. An order must be 
accompanied by a signed "SOFTWARE RELEASE AGREE^IENT". 

The present distribution tape contains the six files described below. 

1. A description of the tape contents, including sample JCL for installing 
the Compiler. 

2. A load nodule library containing the Compiler, a one-step monitor, and 
run-time library routines. 

3. The AO-page manual "MANITOBA PASCAL USER GUIDE" in upper and lower case 
characters, which describes features and restrictions of this implementation. 

A. Sample PASCAL programs. 

5. IBM 360 Assembler source for the Compiler initialization routine. 
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The 80--par,e manual "r^ANITOBA PASCAL CODE GENERATION" in upper and lower 
case characters, v/hich describes the run--time organization and 
demonstrates the code generated for most constructs in the language. 
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- The program heade 
be provided. 



is not required. SYSIN and SYSPRINT must always 



Software (name) 



UNIVEKSIIT OF JIANITOM 

departjie:,'!' of COIG^UTKR SCIEHCi: 

WIUMIPEf;, MA!fITOr,A, CANADA 

R3T 2112 



SOFTWARE RELEASE AGREEMENT 



Manitoba PASCAL Compiler, Version 1 



2... 



RELEASE AGREE! EtIT 



The License shall be non-exclusive and the University of Manitoba 
Dsparttnent of Computer Science shall have the right to p.rant any 
further and additional licenses or to make such other use of the 
codinf, as it shall desire. 



6. 



The above named software is released on 
attached schedule. 



no-fee basis/as per 



GO 
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The undersigned, representing the educational institution or corapany 
identified belov7, accepts the software named above and agrees to the following 
conditions regarding its use and/or distribution. The University of Manitoba 
Departnent of Conputer Science in turn, grants to the belox>f-nained a non-exclusive 
and non-transferable license to use the above named software subject to the 
following conditions. 

1. Softx7are is distributed to educational institutions and companies 
only; not to individuals. The educational institute or connany 
named belox^ agrees to maintain control of the released software, 
and not to redistribute it to any other individual, institution, 

or corapany without the express written permission of the University 
of Manitoba Department of Computer Science. 

2. All credits in listings and/or documentation whether names of 
individuals or organizations, will be retained in place by the 
receiving organization unless written release from this re- 
sponsibility is obtained in t/riting from the University of 
Manitoba Department of Conputer Science. The Licensee shall take 
all reasonable precautions to maintain the confidentiality of the 
coding; at least equivalent to those em.ployed by the Licensee 
with protection of its own confidential information. 

3. All software is released on an "as is" basis, and no warranty as 

to performance or effect on hardware or other software is orpressed 
or implied. The University of Manitoba Department of Com.puter 
Science accepts no liability of any kind in releasing the above-named 
software. 

A. In releasing the above-named software, the University of Manitoba 
Department of Computer Scieiice accepts no responsibility for 
installation, maintenance or functioning of that software except 
thpt refunds will be made if requested within 90 days, and 
accompanied by return of all software materials and a statement 
that no copies have been made or retained. Responses to reasonable 
requests concerning the above-named software will be made by mail 
or telephone. • 



This distribution doss not entitle the Licensee to future releases 
of any of the above-named softv/are. 

The above named software is released in binary form. The distri- 
bution medium is magnetic tape, the format of which is described 
in the documentation. 



(please print) 

Name : 

Title: 



Organization: 
Address: 
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Authorized Signature: 
Date: 



For the University of Manitoba Department of Computer Science 
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I'ASCAL OllDER FOR,'! 

Please send a distr:ibuLion tape containiuf; tlie Manitoba PASCAL Coiv->il(^.r ^ Vc^rr-ir,v. "- 
I have read and af.ree to the conditions .set out in the SOFTWARE RKLFASF AnKl'lK' i;:. r. 

SICI^AfURT: IIArli: 

rOoITIOM 



DATE 



::ducatio:>al itjstitutioii 



(::CTrC: a signed copy of the SOFTWARE RELEASE AGREEMENT nuist accompany this request.) 
Conputer Syste/a on which the PASCAL Compiler is to run: 



Manufacturer 



Hod el 



Total MeiAory 



■leuory available for PASCAL Compiler 



Operating; System with release namber (if any) 
Tape Densities available 



For what purpose do you intend uGin[^ the compiler? 

\aict other PASCAL Conpilers or Interpreters 

(a) do you have on your syster.i? 

(b) have you used? 

Do not send a tape; tapes x-;ill be supplied out of the distribution fee ($50, payable 
to: Department of Computer Science, University of Manitoba). 

l.arne and Address for distribution of the P/iSCAL Conpiler: 



The SUNY Stony Brook Pas 
it is implemented in XPL 
information was answered 
description but with no 
it is reproduced below, 
under OS/MVT, OS/MFT, an 
Two independent parti 
Steve Bellovin's letter 
in their complaints. 



cal compiler is to its credit, very standard. However 
and is very large (180K bytes). Our request for more 
with a 14 page (unfortunately badly faded photocopy) 

letter explaining details. An order form was sent and 
Page 7 of the documentation states that it will run 

d VS/2. It comes with a resident monitor written in BAL. 

es have reported the unreliability of the compiler. See 

in the OPEN FORUM (18 June 1975). Another site phoned 
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Xhc Stony Brook PASCAL/360 compiler is being aade freely 
available, and there are no reetrictlona upoa ita u£ti. Redistribution 
iB also expreaaly permitted but no fee is to be charged for redistribution 
of all or any part of the software or docuaantation furnished by us. 

We must ioiposft a charge of U.S. $175.00 to defiay out costs of 
distribution tape; docxix^atatlon, maintenance through March, 1977» arid 
dlatrlbatlon of malatenance updates. This charge 1& not a us^i fee, nor la 
amy charge being oade for development of the compiler. 

The distribution tape Includes 19 files containing source code 
and object code for the conpiler, an eatecution monitor tliat provides on 
Interface to OS/360, soms utility programs that will be needed for caintenauc 
end sufficient documentation to install the syateiu. 

The initial distribution will be followed by one copy of the 
written documantation of the compiler, and by periodic oaintenance updatea 
in the form of card decks or minirecls of 9-track tnps, Matnttiaauc« is not 
subject to any warranty, cither explicit or iiaplied, beyoiid the aanurance 
that the user will receive any updates that we generate through March, 1977. 



Professor R.B, Klftburtz 
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::;iil to: 



TASCAL Distribution Monaji;cr, 
DopartniGuit of Conputor Science, 
UnivGi\sity of Manitoba, 

riiTniri/; , nanitoba, 

Canada il3T 2112. 



ORDER FORM 

TO: PASCAL Compiler Project 

Departttemt of Computer Scionca 
Sirre at Stony Brook 
Stony Brook, N.Y. 11794 

Plaaae send a copy of the PASCAL/ 360 distribution tape, 
and put ay naaui on tha distribution list to receive fxrcther 
docuaontaXJUja and updates, I agrie that ycu vill rccftiv»i 
p.ji3s»«at of $175.00 from ca or ay inscltut Ion. 

kECOeSKSK^SrCDEHSITYJ NAME: 

80<^bpi / :?.&r^ b?l (Circla ona) tNSriXUTION.- 

i>i Xllp^ Address, iJ: auparata i /j^X) AJJDiOiS.S: 
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IBM 1130 (no known implementations) 

ICL 1900 (an implementation exists) 

2970 (an implementation is planned) 

INTEL 8080 (we need more implementation information) 

INTERDATA 7/15 (an implementation is underway) 
70 (no known implementations) 

MICRODATA 800 (no known implementations) 

MITSUBISHI MELCOM 7700 (an implementation exists) 

MOTOROLA 6800 (we need more implementation information) 



under the EXEC-8 operating system and can be used in Demand mode. Another feature 
is that "Brinch Hansen style Sequential Pascal" programs are accepted under one 
compiler option. No performance or resource requirement data is available. 

To obtain a copy of the system, write to Michael S. Ball, Code 2522, Naval 
Undersea Center, San Diego, CA 92132, (714) 225-2365, requesting a copy as a member 
of USE (*The Univac Users organization*). Include a tape, and if there are any 
limitations on the format please note them. 

This compiler was developed from Pascal -P2, and is documented in a 29 page 
machine retrievable document entitled: "Pascal 1100". The document is in the form 
of a supplement to the book Pascal User Manual and Report . Actually the details 
explained in "Pascal 1100" indicate that this implementation is a powerful tool 
for writing all kinds of software, especially that for writing new EXEC->8 commands. 

Many of the extensions available in the CDC 6000 implementation are present 
so that portability between these two versions is better than just Standard Pascal. 

The compiler accepts the full ASCII character set (strings are packed 4 per 
36 bit word - 9 bits per character). Sets have 4 word representations allowing 
the convenience of defining a set of char. 

Minor restrictions from Standard Pascal are as follows: the symbols: entry ^ 
processor , and univ are reserved; Sets have at most 144 elements; standard 
procedures and functions cannot be used a actual para meters to other procedures 
add functions; it is not possible to construct a file of files. 

We are looking forward to more information on Univac 1100 implementations, 
especially performance data. 
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NCR CENTURY 100^ 200j 300 (no known implementations) 
PHILIPS P-WOO (a non-standard implementation exists) 
SEL 8600 (an implementation exists) 
SIEMENS 150 (an implementation exists) 



XEROX SIGMA 6 (no implementation information) 
SIGMA 7 (implementations exist) 
SIGMA 9 (no known implementations) 
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TELEFUNKEN TR-^^0 (an implementation exists) 

TEXAS INSTRUMENTS TI-ASC (no known implementations) 
TI-980a (implementations exist) 

UNIVAC 1100 SERIES 



Three implementations have been under development. One, by J. Steensgaard-Madsen 
Datalogisk Institut, Sigurdsgade 41, DK-2200 Copenhagen, Denmark is described in 
Newsletter #4. There is no distribution information available. Another project 
is still underway (not complete) by Charles Fischer and Richard LeBlanc at 
MACC, University of Wisconsin, Madison,. WI 53706. (608) 262-7870. Its first release 
is not expected for a few months yet. 

Especially for persons in North America, most encouraging is the news from 
Mike S. Ball at the Naval Undersea Center in San Diego. On July 16, 1976, he 
announced that a fully standard Pascal compiler generating relocatable code which 
can be linked to subprograms written in assembler or FORTRAN. The compiler runs 
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PASCAL USER'S GROu? ALL PURPOSE COUPON 

USER'S 4f'}«-*^4«'^«"4t#*'j^*#*^###-» 

GROU? 

Clip, photocopy, or reproduce, etc. and mail to: Pascal User's Group 

c/o Andy Mickel 
University Computer Center 
227 Exp Engr 
University of Minnesota 
Minneapolis, MN 55455 

(phone: (612) 376-7290) 

// Please ^^"^^ "^y "^^"^'^^^^^^'P ^" the PASCAL USER'S GROUP for the "^^^ Academic 
/ / r I ease ^^^^^ ^^ ^^ ^ member of ^"^ ^^^^^ ^^^^ -^ ^^^^^ ^^^ ^"^ current ^"^^"^^^ 

Year ending June 30. I understand that I shall receive all 4 issues of 
VcUdoZ Hm^loXtvi for the year. Enclosed please find $4.00. 

/ / Please send a copy of VcacaZ Nm^l^ttoji Number . Enclosed please find 

$1.00 for each. 

/ / My nev/ address is printed below. Please use it from now on. I'll enclose an 
old mailing label if I can find one. 

/ / You messed up my address. See below. 

/ / Enclosed are some bugs I would like to report to the maintainer of the 

version of Pascal. Please forward it to the 

appropriate person so that something can be done about it. 

/ / Enclosed please find a contribution (such as what we are doing with Pascal 
at our computer installation), idea, article, or opinion which I wish to 
submit for publication in the next issue of Pa^aal Um^loXtM, . 

I I None of the above. 



Other comments: From: name 

address 



phone 
date 



(*Your phone number helps facilitate -communication with other PUG members.*) 



return to: 

University Computer Center 

University of Minnesota 

227 Experimental Engineering Building 

Minneapolis, Minnesota 55455 



return postage guaranteed 



